My goal here is to attempt to describe the technical details of the situation. I’ll discuss my personal position (I favor Apple) on my other blog, and add a link here.
Let me be clear at the outset. I do not have any inside information on this. What I know comes from public news reports. I have been attempting to understand the issues based on that. It is entirely possible that I have some of the details wrong.
This is about an iPhone, used by the San Bernardino Terrorists. The FBI wants access to that iPhone to help in their investigation. It is entirely reasonable for the FBI to want access.
For this month, I used an external drive. It’s an old ATA 80G drive that I have mounted in a USB disk enclosure. I connected the external drive to my laptop, so that I could do more testing of WiFi and NetworkManager.
I installed snapshot 20160107. I did that install yesterday. And a few hours later, snapshot 20160108 was announced. Well never mind that. I was testing for install problems.
To install, I downloaded the DVD installer (64-bit), and wrote that to a USB flash drive using the “dd_rescue” command.
I plugged installer USB into my laptop. At this stage, the external drive (the install destination) was not connected. This was deliberate. That drive is bootable. When I tell my system to boot from USB, I am not given a choice of USB. So, to avoid any ambiguity, I made sure that the installer USB was the only one connected. I should add that my laptop uses legacy booting.
I saw a Distrowatch announcement of a new release of KaOS, so decided to give it a try. From there, I followed the link to the release announcement.
My previous experience with KaOS was in April, where it failed to install. This time, I had a better experience.
KaOS is a rolling KDE based distro. It is using plasma 5. The new version came with a beta release of plasma 5, so gives me an early look of what I can soon expect to see in opensuse Tumbleweed. The downloaded system uses a release-candidate for Plasma 5.4.
I check the torrent link, but that seemed to be for an earlier release. My understanding is that torrent downloads are provided by users, and I probably looked before they had set it up for the new release.
[update: please check the comments]
I finally got around to signing a kernel. That went pretty well. So I thought that I would describe what I did.
This post presupposes a little knowledge of digital certificates. If you are looking for a quick introduction, try my post on my other blog.
My test machine has opensuse Tumbleweed. But it also has Mint 17.1 (updated from the Mint 17 that I installed). UEFI booting has been working well with Tumbleweed. But I installed Mint without secure-boot support, so I had to leave secure-boot disabled to boot it.
In more detail, I installed Mint in legacy MBR booting mode, because I did not want to clutter the UEFI name space. That worked fine. I could then UEFI boot it anyway, either with the generated grub menu for Tumbleweed or with a “configfile” command that I added to that menu. But secure-boot did not work, because the installed Mint kernel was not signed by an accepted key (it was not signed at all, it seems).
The TrueCrypt home page now says:
The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
The page now offers advice that Windows users should switch to BitLocker, and gives advice on how to do that.
If you are a linux user, the best choice would be to use LUKS encryption.
There are rumors floating around as to what is behind this. But maybe the developers are just deciding that the original need for TrueCrypt has passed, now that most recent systems have their own way of handling encrypted disks.
Personally, I chose LUKS for encryption on linux. So the apparent end of TrueCrypt does not affect me.
According to an announcement that I saw today, it is now possible to use “cryptsetup” with “truecrypt” volumes.
The announcement was on the lizards mailing list, and also showed up in opensuse forums.
I have not tested this. The “man” pages for “cryptsetup” do explain how to use it to access a truecrypt volume. There is currently no support for creating a “truecrypt” volume with “cryptsetup”.
The other way of using “TrueCrypt” is to install “realcrypt” from the packman repos (also not tested).
Bruce Schneier has a new blog post:
It’s about a new research paper on the weaknesses of random number generators such as the one use for “/dev/random” and “/dev/urandom” in linux. Check Schneier’s post for the abstract of the paper, and a link to the full paper.
Thus far, I have only skimmed the paper, so I won’t be explaining it here. But I shall use this post to explain why it is important.
The main use of random numbers is in cryptography.
RC1 (release candidate 1) was available on the download site yesterday. In this post, I shall give my impressions.
As is my usual practice, I downloaded the isos, and wrote them to USBs for testing. My main focus was on the install problems that we had seen with the earlier Beta1 release. Sad to say, some of those problems are still there.
Booting a live KDE system
My first test was to boot a 64-bit live KDE system. That went pretty well. I was pleased to see that the problems with Beta1 and some of the milestones have been corrected. In particular, “/boot” had the kernels needed for installing. While I have not tried installing from the live KDE image, it looks as if that would go well.
I have spent much of my day with installing the Beta release. Thorough testing will have to wait. For now, I will report on how the installing went.
The installing experience can reasonably be described as “interesting”. It is only a beta, so we expect things to go wrong. If we learn from our mistakes, then there could be a lot to learn from this.
I have three completed installations of the Beta. They all look as if they are smooth running systems, though I have not adequately tested them. But installing was another story entirely.
The Milestone 2 pre-release version is available. I downloaded yesterday, and have installed on two systems. One of those installs was 64-bit on my UEFI box, with encrypted “/home” and encrypted swap. The other was 32-bit on my oldest hardware (a semi-retired Toshiba laptop) with randomly encrypted swap.
Here’s the “official” announcement:
The install’s went pretty smoothly. In particular, most of the problems that I ran into with a UEFI install of 13.1M1 seem to have been solved. This may be mostly due to kernel changes.