I’ve just built the latest version of CQRLOG, version 1.6.1, for Fedora 18 through 21. The packages are being pushed to the updates-testing repos now and should be available soon. If you use CQRLOG in Fedora from the repositories I’d appreciate you testing this latest build and giving karma if it works (or doesn’t work) for you.
This update provides the following enhancements and bugfixes:
- 630M band added
- added OQRS (online QSL request system) to QSL sent menu
- added “Always sort by QSO date” option to Search function
- cursor is moved to last opened log in DB connection window
- “Ask before creating a backup” option to “Auto backup” added
- band map is much faster, a few optimization added
- program freezed for a few milliseconds with every bandmap refresh – fixed
- “MySQL server has gone away” problem fixed
- membership values collation were case sensitive – fixed
- ADIF import sometimes crashed with access vioalation, now will show what happened
- qrz search with right click on a call in the recent QSOs list didn’t work
- band map font settings was not loaded when program started
This morning I was greeted with a blog post from the fine folks over at Qualys on how BEAST isn’t really still a threat (unless you are using an Apple product). BEAST, a vulnerability found in SSL and TLS 1.0, was discovered around this time a couple of years ago and put web users in a precarious position of using a poor cipher choice (RC4) or be vulnerable. Not to worry, however, as developers were able to come up with a solution to the problem (n/n-1).
So I mentioned the Qualys article in my $dayjob IRC channel where my always awake coworker provided information that Fedora is, in fact, still vulnerable to the attack. Thanks to a problem with pidgin-sipe connecting to a Microsoft server, the n/n-1 split was backed out of the NSS software leaving anything that depends on it potentially vulnerable (Chrome, Firefox, and Thunderbird to name a few).
There is a fix, although it’s not fantastic by any stretch of the imagination. By simply adding these two lines to your /usr/bin/firefox file the vulnerability should be fixed:
We added these two lines at line 36 and restarted Firefox. My way-too-awake coworker did a test and confirmed that it was working in his environment. Your mileage may vary.
Hopefully the fix for BEAST can be reapplied to NSS in Fedora soon as leaving users exposed can be dangerous.
Thanks to Hubert Kario for pointing me, and walking me, though this stuff before my morning coffee.
Update: 2013-09-12 @ 14:30 UTC
Apparently this problem will be persistent according to the NSS package maintainer. From the ticket:
I bit of information from the nss side of things. The nss disabling patch is not applied on Rawhide or f20, onlt applied on stable branches. After we branch Rawhide for the next fedora release and we enter in Alpha, I send emails to the fedora development mailing list telling them that NSS_SSL_CBC_RANDOM_IV=1 will be the default as they use updates-testing and ask for feedback on whether it causes problems. Twice they have said it still causes problems. There are still unpatches servers out there. Once we go beta I have to enable the patch again. f20 is entering Alpha soon so I’ll send that email again. I know this bug is for Firefox but I though worth informing you that we monitor this every six months for nss.
Update: 2013-10-10 @ 15:22 UTC
Update: 2013-10-17 @ 10:32 UTC
I believe this problem has been fixed (finally!) for Fedora 19 and beyond.
On Sunday, 08 September, upstream developers released version 1.6.0 of CQRLOG. This update has been pushed to the testing repositories in Fedora for versions F21, F20, and F19. Three +1 karma feedback gets the update into the normal Fedora update repos sooner. Please give it a test.
Since upgrading to Fedora 19 I’ve been working out the kinks. Today I was finally able to run one of my problems down and fix it. It involved the failure of my MTA to deliver mail due to a TLS failure.
This failure was working against both postfix and ssmtp. After much log searching I was able to determine that ssmtp wasn’t verifying the public certificate of the distance SMTP server against the CA certificates I have on my system. I was able to confirm that the problem existed on other Fedora 19 systems and that it wasn’t just my crazy setup. After working with a couple of developers it seems that the ssmtp configuration file now requires the entry “TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt” to function correctly. It is not currently known what changes were made that created this problem.
I have not troubleshot postfix as of yet but I suspect a similar solution will be needed.
I went to sign an outgoing message tonight and my Gemalto USB Shell Token wouldn’t light up when I plugged it into my USB port. After doing the typical troubleshooting I am left with the thought that the device has given up the ghost. This isn’t a big problem because I saved the card the SIM came out of and I’m able to use my token on my personal laptop with a traditional card reader. My work computer, however, does not have one of these fancy card readers (maybe I can find my USB one somewhere?).
I can buy another Gemalto device but I’m wondering if there is a better device to use? I mean, the Gemalto lasted almost 500 signatures. But I guess I can now take advantage of the failure to try something else. Does anyone have any suggestions?
When Fedora Badges hit the streets I was excited. I could see several possibilities in the project and I hoped it would be a good way to recognize people for their hard work. Here’s my take on the program.
What it does
Fedora Badges is a lot like the military’s medal and ribbon award system only a lot cleaner and somewhat less dangerous. Each badge has its own criteria for obtaining it. Take, for example, the “In Search of Bull (Tester I)” badge. To receive this badge all you need to do is test and add karma to one updates-testing updates in Bodhi. That’s it. Do that and you get a pretty badge that looks like:
Rewarding hard work
So like I mentioned before, the Badges project helps recognize people’s hard work. Sure, lots of people (199 as of this writing) qualify for the Tester I badge because over the course of their work in Fedora they’ve tested a package before it was pushed to the repositories. But not many (I count 5) have made it to the “Both Bull and Self Transcended” level which requires testing of at least 250 packages. It takes someone special to achieve that level of
Getting people involved outside their comfort zones
Another thing I like about Badges is that it allows people to see other activities that they may not know about or haven’t felt like they could do. If someone looked at my badge wall they’d quickly see what is easily obtainable with very little skill. Maybe they’ve never edited a wiki page or participated in an IRC meeting but those are two things that anyone can do to earn a badge while being a contributor to Fedora (while you’re at it reset your FAS password). Maybe we’ll get a few more people watching Bodhi for updates to software they use and will be able to give feedback that is helpful to the packager.
Gaming the system
Sure, there will be people out there that will game the system to get badges. But is that all bad? I have found myself wanting to get a Tagger badge but had never gone into that system and really knew little about the program. But I did go in to make a contribution and even if I did tag a few packages just to get a badge I did provide a service towards that project and helped them get a few more packages tagged. The best part is that I gave it a try and found something else I might like doing within the Fedora Project. I wouldn’t have done it otherwise but I might go back to help do more package tagging.
I really like this Badges system and I hope others will take a look at it and perhaps branch out into other aspects of this great Project. From answering questions on ask.fedoraproject.org to submitting builds to koji there is always something else people can explore. Maybe you’ll find something new within the Project to add to your list of activities. I know I have.
Pretty much as soon as I had pushed the 0.9 version of tudu version 0.9.1 became available. The test packages are available for testing. Add karma points if works for you (and, obviously, negative karma if it doesn’t). Thanks!
Ever since I started contributing to the Fedora Project I’ve always loved the work (still do!). The operating system is flexible (just a bunch of puzzle pieces, really) and that flexibility allows people to build pretty much any type of system they need to get their work done. Everything being licensed under a free and open source license makes all those puzzle pieces very easy to work with as well. In short, what I see in Fedora is what I’ve come to expect from all software solutions.
An almost common topic on the Fedora Board is the “target audience”. I dread these conversations because the conversation has never made much sense to me. To me, Fedora is flexible enough to be whatever anyone wants it to be. If you need to use Fedora on a server to serve up web pages or email it can do that. Need it to be your primary operating system on your laptop? Yep, it does that well too. So why do we spend so much time, energy, and effort on the “target audience”? I have some theories, which I won’t discuss here, but in short we really shouldn’t be trying to pidgin-hole ourselves when our flexibility is one of our major selling points.
For years now we’ve made some assumptions about our “target audience” and what that “target audience” wants. The assumption of what they want ends up being the default offering and everything else becomes a Spin. I’ve been on the Board now for a year (just entering my second term) and I’ve yet to hear any evidence that says that this is what our “target audience” wants and why we need to push the hard work of other SIGs down to second-class citizen level. It doesn’t matter that Fedora runs on tablets, headless ARM devices, servers, cloud environments, and pretty much anywhere else people can think of putting it. We still think that everyone wants the GNOME Desktop Environment with all the bells and whistles for every installation or that you can just manually add and remove packages or by use a kickstarter file at installation to fix these issues.
So before it gets brought up in the next Board meeting (taking place in just over twelve hours from now) I figured I’d take the opportunity to explain my thoughts on the idea. Why don’t we let the SIGs determine what’s important and let them build the releases that create Fedora offerings? The Desktop SIG could put together what they wanted as could a Server SIG, ARM SIG, cloud SIG, etc. The new download page could display several desktop environment downloads, server ISOs, cloud images, and perhaps several ARM images to allow specific hardware goals to be more easily met. The Project could focus more on the core packages and then help the SIGs develop their releases. This isn’t exactly different from what we already have, as far as logical people layouts are concerned. Today there are people who work under several SIGs and sometimes the work they do also falls across those lines of interest. The biggest change would be that Fedora would no longer be only known for its desktop OS but rather it would be known for its flexible OS that is pre-built for many situations making it easier for people to adopt it for their use.
Lets add another foundation to our current four. Let’s make it five with Flexible.