The real story behind Arch Linux package signing(toofishes.net)
toofishes.net
The real story behind Arch Linux package signing
http://www.toofishes.net/blog/real-story-behind-arch-linux-package-signing/
4 comments
Arch is an amazing distro and every one of my experiences with the community have so far been positive. Kind of a bummer to see people dumping on it in the mailing lists and LWN.
Besides its core philosophy and approach, I like Arch for its community. Its forum and IRC channel are among the rare places on the Internet where you can openly talk about flamewar-inducing topics (like foofs vs barfs or vim vs emacs) while avoiding ignition point and actually have a constructive discussion.
I witnessed rare similar cases of the random guy knocking on Arch's door and raving in about how he knows the world and everything and that we should all bow down before him but it never escalated to the point it has on that precise case.
I witnessed rare similar cases of the random guy knocking on Arch's door and raving in about how he knows the world and everything and that we should all bow down before him but it never escalated to the point it has on that precise case.
Agreed on the thumbs up for Arch; I'm not thrilled with the direction Ubuntu has been taking recently (at least in the desktop version) and so have been migrating my non-server Linux boxes to Arch.
Sad to see LWN publish an attack without making an effort to get the other side of the story first. If the complainer had made the patch submissions he claimed and that the Arch maintainers deny ever seeing, well it should be pretty easy to sort out before publishing the article -- if you're really interested in journalism, that is.
Sad to see LWN publish an attack without making an effort to get the other side of the story first. If the complainer had made the patch submissions he claimed and that the Arch maintainers deny ever seeing, well it should be pretty easy to sort out before publishing the article -- if you're really interested in journalism, that is.
What's wrong with Ubuntu's direction, according to you?
To me, it seems they are fighting really hard to make Linux a user friendly desktop platform. Even if it leaves behind some ways of working that us older Linux users are accustomed to, I think this is a worthy cause.
To me, it seems they are fighting really hard to make Linux a user friendly desktop platform. Even if it leaves behind some ways of working that us older Linux users are accustomed to, I think this is a worthy cause.
Well, it's just my personal opinion, but it seems to me that the 6-month release cycle has practically guaranteed they would add new features before they were ready and consequently screw up something that seemed to work just fine before (e.g., Pulse audio). Frankly, that's not a trait I think that makes Linux user friendly for newbies. Now they seem to be screwing over the visual interface in a fit of Mac envy that doesn't include Apple's commitment to polished products. I hated the imperial decision to move window buttons from the top right to the top left, for example. Yes, it was simple to fix, but why should I have to when it was working fine before? (Plus that change only makes your users more comfortable if they're coming from the Mac instead of a Windows experience. The idea that Mac users will move to Ubuntu for the user experience I find extremely dubious.)
And now we're getting the Unity interface before it's really finished. I really think the new interface is something that works on netbooks but is a step backward if you're using a widescreen monitor or regular laptop.
But I'm just a knuckle-dragging throwback who likes minimalism, xmonad, and Vim, who doesn't stream audio over the network and thinks ALSA was perfectly adequate, etc., so what do I know? If I'm the sort who's happier with Arch, then I'm clearly not their target user anyway. YMMV.
And now we're getting the Unity interface before it's really finished. I really think the new interface is something that works on netbooks but is a step backward if you're using a widescreen monitor or regular laptop.
But I'm just a knuckle-dragging throwback who likes minimalism, xmonad, and Vim, who doesn't stream audio over the network and thinks ALSA was perfectly adequate, etc., so what do I know? If I'm the sort who's happier with Arch, then I'm clearly not their target user anyway. YMMV.
See the [Arch Way](https://wiki.archlinux.org/index.php/The_Arch_Way), notably #1. Having a barebones system installed allows you to shape it any way you want (LFS style, without the hassle of bootstrapping and lack of package management), and sticking with as much vanilla packages as possible allows you to just use upstream doc, and makes bug hunting easier to report upstream too.
Ubuntu is the antithesis of that (no judgement here, I am fairly marvelled at the "pop the CD in and it just works" result of Ubuntu).
Ubuntu is the antithesis of that (no judgement here, I am fairly marvelled at the "pop the CD in and it just works" result of Ubuntu).
Part of the beauty of Linux is that people that don't like the direction of a particular distro can jump ship to another one. Does it really matter why? If enough people are jumping ship, then it's probably time to question your roadmap, but a few people here or there (especially if they are not your target audience) aren't an issue.
I'm simply interested in what his reason is, not trying to question the wiseness of his decision :) I agree that there is nothing wrong with switching to a different distribution if it suits you better.
Yes, FWIW I took it as a request for information, not as an invitation to a Klingon death match because I'd insulted your family's honor. I celebrate diversity! ... even as I remember Philip K. Dick's liberal translation of de gustibus non est disputandum as "those people can have bad taste and I don't care."
What are you unhappy about with Ubuntu?
It's just personal preference. I like getting updates to applications and kernels with the six-month release cycle, but their new interface release cycle seems rushed. With Arch I have even faster access to app and kernel upgrades without the gratuitous (to me, at least) system changes.
You want to upgrade users to grub 2.0? OK, not a pressing need for me, but fine, whatever. But at least when you make that change include system support so I don't have to manually repair the grub menu's default selection every freaking time you update the kernel. </rant mode>
You want to upgrade users to grub 2.0? OK, not a pressing need for me, but fine, whatever. But at least when you make that change include system support so I don't have to manually repair the grub menu's default selection every freaking time you update the kernel. </rant mode>
People want a feature, but nobody wants to code it. It's obviously either: a) not that important, or b) people don't want it that badly.
Or c) those who want it don’t have enough skill to code it, and those who have the skill aren’t interested.
That’s the generalized response to the flawed argument “if you want it, why don’t you make it?” in open source. People specialize at tasks to hopefully increase the total effectiveness of a system to more than it would be if everyone did everything. However, this means that if the only people who have the power to do something unionize, other people can’t get that thing without agreeing to their demands.
You could say in this situation, the core devs of Arch “unionized” to demand either coding help or patience from those who want the feature. I’m not interested enough in this situation to be bothered to research whether this is a reasonable demand. If it is unreasonable, c) is the case, and if it is reasonable, a) or b) is, but that’s as far as I care to investigate.
That’s the generalized response to the flawed argument “if you want it, why don’t you make it?” in open source. People specialize at tasks to hopefully increase the total effectiveness of a system to more than it would be if everyone did everything. However, this means that if the only people who have the power to do something unionize, other people can’t get that thing without agreeing to their demands.
You could say in this situation, the core devs of Arch “unionized” to demand either coding help or patience from those who want the feature. I’m not interested enough in this situation to be bothered to research whether this is a reasonable demand. If it is unreasonable, c) is the case, and if it is reasonable, a) or b) is, but that’s as far as I care to investigate.
> Or c) those who want it don’t have
> enough skill to code it, and those who
> have the skill aren’t interested.
Those who want it, but don't have the skill
to code ti, want to demand that someone that
has the skills, spends their leisure time
creating it for free because they don't want
to pay for it.
If it is really that important to you, and
you don't have the skills to do it, you always
have the option of paying someone that *does*
have the skills to do it for you.
What about hashing? Even if hashing is not the best solution, a not-so-good solution is preferable over 7 years of a hole. This is the attitude that make users mad.
edit: I am talking sha256sum to compare with master repo. see: https://bugs.archlinux.org/task/23101#comment73640
edit: I am talking sha256sum to compare with master repo. see: https://bugs.archlinux.org/task/23101#comment73640
That's what capitalism is for.
If you don't have something you want and I have (the skill to write this patch), instead of bitching and griping, make it worth my while to do it for you.
If you don't have something you want and I have (the skill to write this patch), instead of bitching and griping, make it worth my while to do it for you.
Indeed. I work on several open source projects. When a user wants a certain feature really bad, can't code it himself and can't wait for my schedule, then they can always pay for my time to implement it. Problem solved.
Well c) isn't really the case in Mr. WhinyUser's second request, to add SHA256 hashes. He originally claimed it was "really easy" to do, but balked at actually providing any code unless the maintainers promised to accept it. A couple of days later Dan implemented the change -- without any help or thanks from Mr. WhinyUser.
I don't know that the union argument really works in the Linux distribution realm. After peeing in the community pool Mr. WhinyUser went off to a fork of Arch that supports signatures (for their additions only, which doesn't appear to address his original concerns about Arch repositories, but apparently for some the appearance of "security" is enough). But even if he didn't have that fork to go to, there was nothing stopping him from adopting one of the many Debian offshoots, or Redhat, or ... The Arch maintainer union -- really an odd term for a handful of unpaid volunteers -- have no control over his actions or desires, but there are plenty of Linux distribution alternatives out there.
I don't know that the union argument really works in the Linux distribution realm. After peeing in the community pool Mr. WhinyUser went off to a fork of Arch that supports signatures (for their additions only, which doesn't appear to address his original concerns about Arch repositories, but apparently for some the appearance of "security" is enough). But even if he didn't have that fork to go to, there was nothing stopping him from adopting one of the many Debian offshoots, or Redhat, or ... The Arch maintainer union -- really an odd term for a handful of unpaid volunteers -- have no control over his actions or desires, but there are plenty of Linux distribution alternatives out there.
I am with you on this and with IgnorantGuru on the issue (I don't even care about the lies).
There is no rational explanation that justify why a really major issue, or for that matter even simply an issue most users want, should not be implemented by the core developers for 6 freaking years. If you are too busy to code, you should step down and leave the position; same thing if you think the bug is not one of your personal priority: you are the maintainer and you have taken up a responsibility towards the users. Abandon if you cannot do it.
I had my own little delusion with nautilus developer, of which I talk here ( http://gilest.ro/2011/patches-for-nautilus-move-to-trash-bug... ). Same attitude there: lots of people want the bug fixed, patches exist, won't fix.
There is no rational explanation that justify why a really major issue, or for that matter even simply an issue most users want, should not be implemented by the core developers for 6 freaking years. If you are too busy to code, you should step down and leave the position; same thing if you think the bug is not one of your personal priority: you are the maintainer and you have taken up a responsibility towards the users. Abandon if you cannot do it.
I had my own little delusion with nautilus developer, of which I talk here ( http://gilest.ro/2011/patches-for-nautilus-move-to-trash-bug... ). Same attitude there: lots of people want the bug fixed, patches exist, won't fix.
If the users were seriously demanding the feature, then at least someone would have stepped up to code it. It's my understanding that most of the users of Arch Linux are not exactly a technically challenged bunch.
There's also the lack of any chatter on the issue for long periods of time. If this was such a serious issue that so many users wanted, then why only a handful of discussions about it over the past 6 years?
I find it a little disturbing that you've just latched on to the part of the issue that hits home for you (developers ignoring a patch) and are ignoring other stuff (e.g.):
There's also the lack of any chatter on the issue for long periods of time. If this was such a serious issue that so many users wanted, then why only a handful of discussions about it over the past 6 years?
I find it a little disturbing that you've just latched on to the part of the issue that hits home for you (developers ignoring a patch) and are ignoring other stuff (e.g.):
> (I don't even care about the lies).I don't care about the lies because what I need to know is that there is a major safety issue open since 2006 and the maintainer of the software have not fixed that yet.
I understand that people have their own schedules, I do maintain OSS myself: I am fine with developer taking months or even 1 year fixing stuff. 6-7 years is not justifiable though. If you didn't have time to code something important for an important piece of software you mantain in 6 years, you have no justification towards your user: don't pretend you do.
I understand that people have their own schedules, I do maintain OSS myself: I am fine with developer taking months or even 1 year fixing stuff. 6-7 years is not justifiable though. If you didn't have time to code something important for an important piece of software you mantain in 6 years, you have no justification towards your user: don't pretend you do.
or d) those that don't know how to code it learn how to and start contributing to the thousands man hour project they leach off of.
This happens from time to time in OSS projects. Some users kick up a big stink. Often times their issues get fixed.
However, it's a shit way to do it and tramples on a lot of people... and in the mid to long run can damage a project greatly.
A more constructive way for a user to get a feature in is to either pay for it, or code it. Setting up a 'bounty', or helping to get funding is a better way to try and get these novel writers to help with the project.
Get these passionate writers working for the project by directing their energies towards getting funding. Telling them to shut up and submit a patch won't work... since they are not capable of writing code sometimes. However they do care greatly about the issue, and have time to send off emails and write blog posts.
However, it's a shit way to do it and tramples on a lot of people... and in the mid to long run can damage a project greatly.
A more constructive way for a user to get a feature in is to either pay for it, or code it. Setting up a 'bounty', or helping to get funding is a better way to try and get these novel writers to help with the project.
Get these passionate writers working for the project by directing their energies towards getting funding. Telling them to shut up and submit a patch won't work... since they are not capable of writing code sometimes. However they do care greatly about the issue, and have time to send off emails and write blog posts.
In this case, it seems like the user is more interested in trolling than anything else. He claimed that one of the features was 'easy' to implement and that he would submit a patch, but then never did. Presumably because it was too busy writing a blog post about how the developer was being 'difficult' because they asked him to write a patch for such an 'easy' feature (e.g. "encryption is easy, right? you just take a piece of information and then you encrypt it! Pow! It's done! Easy as pie! What's so hard?").
There was an "Arch Bounty" system for funding things like this. It died with only one donation. It wasn't well promoted, but it did exist and was mentioned on the Arch Linux website in various places. Info is available from an Arch Linux developer at http://archlinux.me/dusty/2010/01/22/death-of-arch-bounty/
Notice the dates. The "Arch Bounty" system was born and died while people complained. People who were complaining about this could have asked for a bounty for this feature and paid for it, but they didn't.
Notice the dates. The "Arch Bounty" system was born and died while people complained. People who were complaining about this could have asked for a bounty for this feature and paid for it, but they didn't.
tl;dr anyone? Arch is the only distro I use but never heard of this before.
Many distributions try to provide some security assurance to users by having packages in the repo cryptographically signed. This makes it harder for naughty people to trick users into installing malicious software. As a relatively small, non-"enterprise" distribution, Arch has not implemented such a system. Some people believe this is a Bad Thing, and recently there has been some controversy about it on mailing lists, which eventually bubbled up into an article on Linux Weekly News. Some Arch developers believe the issue has been portrayed inaccurately, and that a hostile individual has framed the issue unfairly.
As someone who hasn't ever used arch, I am surprised to find out that they don't sign. The distros I use, RHEL, fedora and openSUSE have pushed all signed packages for quite some time. Clearly debian/ubuntu do as well. FBSD and OBSD also. Even gentoo supports signing of portage source packages, though apparently there is no policy that requires package builders to sign. This would seem to be an argument against rolling your own package manager, at least if you lack the resources to bring it up to industry standards.
Does anyone know of other distros that don't sign their packages?
Does anyone know of other distros that don't sign their packages?
RHEL, fedora (RH again) and openSUSE all have paid programmers working on their distro at various companies. Arch does not. I will agree that not having signing is an argument against using pacman the Arch package manager. There are, however, plenty of positive arguments for using pacman. Its a great, reliable, package manager and I'm more comfortable with it than apt-get and yum for sure. If you're interested there are plenty more details in the Arch Wiki.
OpenBSD does not sign patches. They do not release binary patches to base, only source, and they are not signed. Go to misc and ask them to sign patches. They'll flame you forever and suggest if you want to be sure the source is from them to buy one of their CDs.