[pacman-dev] [ Package Signing ] Your signature please
Greetings - I was directed to this list as the place where stuff is getting done on package signing. I would like to share some thoughts on this which I hope you'll give some serious consideration. One, I would like to convince you to change your order of operations slightly to the benefit of both users and developers, and two I would like to share some thoughts on open security approaches. First, thanks to Allan and the others who have put some real effort into making this a reality. Nevertheless it is proceeding very slowly and from what I gather is not being given much priority. Obviously that's because the devs don't feel it is worthy of priority. So be it. But if you're going to proceed this slowly with it, please consider changing your order of operations so we users can help ourselves. Specifically, please put providing signatures first, even before your automated signature checking or your final design is complete. If you need to later change how the signatures are stored or keys or other details, that's fine. But get the packages signed and get the signatures onto the mirrors in some usable form. You're currently having armchair debates about arcane replay attacks while the data on the servers is sitting there completely unprotected, and users have no way of verifying its authenticity. Just getting the signatures out there will improve security by several orders of magnitude. The threat is not just a matter of data integrity on the mirrors, but providing a way for users to verify data coming over their networks, from shared caches, stored locally, etc. As one commenter on my blog expressed: "I think you’ve motivated me to try another Linux distribution after years with Ubuntu. You’ve interested me in Arch too, but there is no way I’m going to install it on my desktop, let alone server before they implement package signing. Their mailing list suggests that this is a milestone of not so near future. Unsigned package installation is a security breach of cyclopic proportions, anyone who hacks your old wifi AP will be able to inject malicious Arch packages by repository proxying, this isn’t even possible with Windows updates." And repository proxying is just one of a whole host of security issues unsigned packages create, which have nothing to do with the security of the mirrors. It's a local thing. Arch is depending on very flimsy security through obscurity at this point - hoping no one will go to the trouble - and providing no options to users. If you require the packagers to routinely sign packages now with their keys, get their keys onto key servers, and get the package signatures on the mirrors, at least we have some way of verifying the data. You don't need to rewrite GPG - it's there. I for one would be happy to write a script that scans the pkg cache and checks the sigs. This way when someone says "Arch doesn't have package signing" we can reply "Actually packages ARE signed - we're working on the automatic checking, until then check them yourself". Archers are very good at this sort of thing. But we can't do anything until the sigs are available, and that requires a minimum of effort on your part. It's probably already implemented. And the security precautions you need to take at this point are minimal - just publish the signatures somewhere - they are self-protecting. You don't have to tell anyone what they should do with them or how they are best used - let us worry about that for now. This will also give you the time to get pacman's automated signature checking available on your own timetable, while your servers have some minimal protection (actually quite a bit). Plus instead of rolling out the whole system at once, you'll have the signing and distribution of signatures and keys already in use - perfect for you to test your checking on the real mirrors, and to be exposed to some of the issues that will arise. And you'll have scripts by then which can double-check your checking, so you don't have to feel like everyone's security is on your shoulders alone. As you've probably noticed by now, security development is a high stress endeavor. Break up the load and let problems be found in a more gradual way. Users who have higher security needs or who operate on questionable networks will then have a way to verify their packages. Users who don't want to be bothered can wait until you finish your pacman adjustments. In short, please make the signatures and keys available ASAP. That's great you're working on your security design and automatic checking, taking your time and being careful, but at least give us some sigs for now so we can help ourselves. On the subject of security formats and protocols, I wanted to throw a few ideas in there. First, I think keeping it simple is very important, especially for Arch. I believe any user with GPG should be able to verify a package, no other tools required, and no digging into databases for signatures. Instead of placing signatures in a db file, I think serious thought should be given to using the built-in encapsulation features of GPG. Why have a separate sig file or db mechanism? Wrap the data in the signature - that way it begs to be checked. It can be as simple as package.tar.gz.gpg And checking it can be as simple as manually running the package through GPG. This is very good for security - users can use GPG directly to examine signatures, keyrings, and anomalies. (Pacman in the short term could be adjusted so it simply removes the signature layer without checking.) Also, devs love to make code efficient, but in this area consider not making that your top priority. There are many PGP/GPG libraries which are ill-maintained compared to the long-lived GPG, and they can introduce security problems. They also further remove the user from control of security, which makes for bad security. I suggest having pacman run gpg for its security needs, in a transparent way to the user. No reliance on other libraries. This will have a minor cost in efficiency, but it is a good KISS model and in the long run will improve security. (Many of the PGP APIs were little more than attempts to weaken PGP.) This also makes your job easier. Why reinvent the wheel? The command line does just fine, and gpg gets much more scrutiny in cryptographic circles than the many libraries that allege to duplicate it. Use the real article. When modifying pacman, don't make it overcomplicated. I think users should have some way to specify a custom keyring to be used, and a way to disable or ignore signature checking. Beyond that, keep it minimal and simple. The more complex you make it, the less secure it will be in real world applications. As for replay attacks, you may want to consider this an opportunity to change the way package management is handled more generally. It has some weaknesses that are not based solely in package integrity. If you try to address those weakness with the wrong tools (such as signatures), you're going to create an unnecessarily complex system with compromised security. I suggest making package signatures available now, then working carefully on the overall management system. Change is good. Obviously Arch devs are new to some of these security models, which I believe is one reason you have shown so much reluctance to tackle it. You don't want to mess it up and be embarrassed. Everyone who works in security plays the fool sometimes - ask Phil. Security is very tough and imperfect work compared to many areas of development, cryptographic security especially so. But don't let this reluctance make you choose a total lack of security, which is the current status quo in Arch packaging. Do your best with it, move on, and do your best some more. The weakest link in your security BY FAR will be the key maintenance practices of the packagers, and the security of their personal systems. They should be advised to self-sign their keys, have their keys signed by others, use strong passphrases, not use passphrase caching or convenience tools of any kind, have 6 month expiration dates on keys, and revoke keys routinely anytime local system security may have been compromised. This issue completely blows away replay threat models in severity, and its an imperfect science. You just do your best. But some guidelines should be provided to packagers at some point, and should be enforced where possible. Yet on these issues, please don't debate them before providing signatures to current packages. Get it started, imperfect as it is. If you change keys, file formats, or protocols later, than is not only fine, but such changes should be considered a routine part of the development of Arch's secure package management. Let's get it started.
On 19/02/11 09:40, IgnorantGuru wrote: <snip>
In short, please make the signatures and keys available ASAP. That's great you're working on your security design and automatic checking, taking your time and being careful, but at least give us some sigs for now so we can help ourselves.
Everything up until this point is not related to pacman development at all and should be taken up with whoever provides the repos you use. Pacman is not Arch Linux specific... Note that the current implementation does not preclude having the signatures alongside packages in the repos. It just uses the version provided in the repo database. Also, if you use "pacman -U <url>" pacman will try downloading any signature alongside the package, so it is more than likely the signatures will end up there. <snip>
Also, devs love to make code efficient, but in this area consider not making that your top priority. There are many PGP/GPG libraries which are ill-maintained compared to the long-lived GPG, and they can introduce security problems. They also further remove the user from control of security, which makes for bad security. I suggest having pacman run gpg for its security needs, in a transparent way to the user. No reliance on other libraries. This will have a minor cost in efficiency, but it is a good KISS model and in the long run will improve security. (Many of the PGP APIs were little more than attempts to weaken PGP.) This also makes your job easier. Why reinvent the wheel? The command line does just fine, and gpg gets much more scrutiny in cryptographic circles than the many libraries that allege to duplicate it. Use the real article.
We are using gpgme which is maintained by gpg developers. So we are not reinventing any wheel. If that is an ill-maintained and contains security issues, then why trust gpg at all?
When modifying pacman, don't make it overcomplicated. I think users should have some way to specify a custom keyring to be used, and a way to disable or ignore signature checking. Beyond that, keep it minimal and simple. The more complex you make it, the less secure it will be in real world applications.
Have you actually looked at the current implementation at all? I'm not sure how much simpler it could get. The package is downloaded and its signature - either in the repo or detached - is checked using gpg via gpgme. There is a way to disable signature check and select which keyring is being used. And that is about it...
Obviously Arch devs are new to some of these security models, which I believe is one reason you have shown so much reluctance to tackle it.You don't want to mess it up and be embarrassed.
Umm... no... the *pacman* devs just feel the have better things to do with their lives, including things of higher interest to develop in pacman. Also, (almost) no-one who considers this super-critical to implement has done anything about it. And those that have obviously have not (yet?) seen it through to the finish. In the end, the only way anything will get implemented is if patches are provided. (That includes the suggestion of providing signatures in repos on Arch Linux - look at that devtools/db-scripts projects). Dan and I have also mentioned our consulting rates in the past, which may or may not increase motivation to finish this... Finally, *succinct* reports on where the current implementation in pacman can be improved are also appreciated. But that requires actually paying attention to what has already been done. Allan
On Sat, 19 Feb 2011 11:21:47 +1000 Allan McRae <allan@archlinux.org> wrote:
We are using gpgme which is maintained by gpg developers. So we are not reinventing any wheel. If that is an ill-maintained and contains security issues, then why trust gpg at all?
I'm not up on the latest in gpg, what is being developed, or how well it has been cryptographically tested, and it sounds like you're not either to some extent. I was offering general suggestions - try to see the bigger picture and the details won't be so much work. I still think using command line gpg gives users better control over their own security solutions and provides better security. But you're obviously too deeply invested in the libraries now to even consider anything else (which is one reason why I advise against them). So be it.
Have you actually looked at the current implementation at all?
I read some discussions of it, but I have not looked at it. Frankly it interests me far less than having signatures available at this point. I trust that you can implement checking. I think you're putting the cart before the horse, which is why package signing is getting nowhere (no real usable results). But if you have kept it as simple as you describe, good work.
In the end, the only way anything will get implemented is if patches are provided. (That includes the suggestion of providing signatures in repos on Arch Linux - look at that devtools/db-scripts projects). Dan and I have also mentioned our consulting rates in the past, which may or may not increase motivation to finish this...
Surely you have some mechanism in makepkg or elsewhere for generating the signatures used in your test repo for your pacman sig checking features. Why not push this through to the packaging or database tools now while you're still working on pacman? Or have you completely ignored the need to generate signatures (I know you haven't from what I've read, so that's rhetorical). It seems you or others are stalling on providing signatures because you want exclusive control of checking those signatures. It's trivial to implement providing them and surely you know that - man gpg for help. Like everything done by committee, I think you're making things more complicated than they need to be. It's okay, I didn't have high hopes for this communication. This issue is obviously too mired in politics and ego for anything to budge (not you personally).
Finally, *succinct* reports on where the current implementation in pacman can be improved are also appreciated. But that requires actually paying attention to what has already been done.
Agreed. FWIW, I think your pacman changes will see reality (as in popular use) much more quickly if signatures show up on mirrors sooner rather than later. Once the sigs are there, the appetite for your pacman work will be there, and the dev politics of Arch will sway. Simply put, there can be no logical or technical reason for not providing signatures for packages. At the minimum, they can only vastly improve the situation, which currently is a complete abdication of any form of responsible package security, and they are trivial to add. The only reason for not providing them is a human one - IOW irrational. I'm no diplomat - I just make things work. I'll leave you to your politics.
On Sat, Feb 19, 2011 at 12:00 AM, IgnorantGuru <jgj7.pacmandev@mailnull.com> wrote:
[.... lots of talk....]
There's no political problems here. It's just lack of manpower to make it. That's it. This is a standard open source community, there's just momentum when there is personal interest. In the other hand, I kind of enjoy your stimulus, because I'm just so lazy..... Sometime I need some push over to make me do things :D Sorry, but it's the truth. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 19/02/11 12:00, IgnorantGuru wrote:
On Sat, 19 Feb 2011 11:21:47 +1000 Allan McRae<allan@archlinux.org> wrote:
We are using gpgme which is maintained by gpg developers. So we are not reinventing any wheel. If that is an ill-maintained and contains security issues, then why trust gpg at all?
I'm not up on the latest in gpg, what is being developed, or how well it has been cryptographically tested, and it sounds like you're not either to some extent. I was offering general suggestions - try to see the bigger picture and the details won't be so much work. I still think using command line gpg gives users better control over their own security solutions and provides better security. But you're obviously too deeply invested in the libraries now to even consider anything else (which is one reason why I advise against them). So be it.
We are not too deeply invested in anything. No release has been made... I was just pointed out that you appear to have no idea what the library we are using is and what it actually does. It makes absolutely no sense to have pacman manually fork a process to run gpg to verify a package/database and then manually parse the output when the upstream gpg developers provide a library to do just that.
Have you actually looked at the current implementation at all?
I read some discussions of it, but I have not looked at it. Frankly it interests me far less than having signatures available at this point. I trust that you can implement checking. I think you're putting the cart before the horse, which is why package signing is getting nowhere (no real usable results). But if you have kept it as simple as you describe, good work.
In the end, the only way anything will get implemented is if patches are provided. (That includes the suggestion of providing signatures in repos on Arch Linux - look at that devtools/db-scripts projects). Dan and I have also mentioned our consulting rates in the past, which may or may not increase motivation to finish this...
Surely you have some mechanism in makepkg or elsewhere for generating the signatures used in your test repo for your pacman sig checking features. Why not push this through to the packaging or database tools now while you're still working on pacman? Or have you completely ignored the need to generate signatures (I know you haven't from what I've read, so that's rhetorical).
It seems you or others are stalling on providing signatures because you want exclusive control of checking those signatures. It's trivial to implement providing them and surely you know that - man gpg for help. Like everything done by committee, I think you're making things more complicated than they need to be. It's okay, I didn't have high hopes for this communication. This issue is obviously too mired in politics and ego for anything to budge (not you personally).
Design by committee implies there is an actually committee making decisions around here, which is far from the truth... The reason the makepkg changes have not been pushed yet is because they are not finished. As someone who has run the gpg branch version of makepkg for a while, I found it really annoying to not be able to disable/enable signing from the command line. I see Denis just sent a patch for that so it may be possible to push the makepkg changes in the future. But that is very unlikely to happen before the next release which is scheduled to occur quite soon. Offtopic: Not that this actually matters as far as Arch Linux is concerned. The support needs added to devtools/db-scripts. The package upload script could have a temporary line in it to do the package signing while waiting on makepkg to do that automatically.
Finally, *succinct* reports on where the current implementation in pacman can be improved are also appreciated. But that requires actually paying attention to what has already been done.
Agreed. FWIW, I think your pacman changes will see reality (as in popular use) much more quickly if signatures show up on mirrors sooner rather than later. Once the sigs are there, the appetite for your pacman work will be there, and the dev politics of Arch will sway.
Simply put, there can be no logical or technical reason for not providing signatures for packages. At the minimum, they can only vastly improve the situation, which currently is a complete abdication of any form of responsible package security, and they are trivial to add. The only reason for not providing them is a human one - IOW irrational. I'm no diplomat - I just make things work. I'll leave you to your politics.
I'll repeat, talk to the providers of the repos about getting signatures provided. This list is for pacman-development only and thus any distribution specific conversation is off-topic.. But to be the guy who "makes things work", patches will be required. Allan
The mail by IgnorantGuru is very much what I was going to write. There is no problem in adding signatures to the Arch repositories immediately. You always say that pacman is not the same as Arch. This might be true, but which major distribution uses pacman? We should not argue about those subtile differences. I pulled the main pacman branch, merged Allan's gpg-patches and created a signed repository - everything worked fine (Except for example overwriting the db with a unverified one before verifing - I can provide patches for this in one week). You always say that you need patches, but what exactly? You seem to have a working implementation but you don't integrate these into master. Instead you work on minor performance issues (Single file database for example) even though we have a very serious security problem. Regards Daniel
On 19/02/11 15:18, Daniel Mendler wrote:
The mail by IgnorantGuru is very much what I was going to write. There is no problem in adding signatures to the Arch repositories immediately.
You always say that pacman is not the same as Arch. This might be true, but which major distribution uses pacman? We should not argue about those subtile differences.
I pulled the main pacman branch, merged Allan's gpg-patches and created a signed repository - everything worked fine (Except for example overwriting the db with a unverified one before verifing - I can provide patches for this in one week). You always say that you need patches, but what exactly? You seem to have a working implementation but you don't integrate these into master. Instead you work on minor performance issues (Single file database for example) even though we have a very serious security problem.
I will repeat myself again... Patches for pacman do bugger all for getting signatures into Arch Linux repos. Patches for the Arch Linux devtools/db-scripts packages are needed. And I will once again point to the package signing TODO page for a list of what we need to do at a minimum before this becomes integrated in the main pacman branch: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing As with all feature branches, they integrated into master when they are finished. Otherwise we can not make a release without actually getting it fully completed or backing out the unfinished work. Given the rate this has been developed, the second seems the likely outcome. Finally, "minor" performance issues interest me a hell of a lot more than package signing. Mainly because that actually affects me whereas unsigned packages really does not... That is why I spent my free time implementing them. Thinking about it, improving optdepends handling, transaction hooks, VCS support in makepkg, adding a test suite for makepkg, automatic creation of debug packages, .... all affect me more than package signing does, so I maybe will start work on package signing again once those are finished. Allan
On Sat, 19 Feb 2011 17:35:21 +1000, Allan McRae wrote:
I will repeat myself again... Patches for pacman do bugger all for getting signatures into Arch Linux repos. Patches for the Arch Linux devtools/db-scripts packages are needed.
To be honest, I don't think it's worth to work on patches for devtools dbscripts right now. I'd prefer to be pointed at some documents which describe exactly the wrokflow to sign a package with makepkg, upload it, add it to a db, update, replace and delete it. Once there is a version of pacman which supports signed packages I can start implementing these ideas. And last but not least we need to think about key management which is less technical but very important. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, 19 Feb 2011 10:25:38 +0100 Pierre Schmitz <pierre@archlinux.de> wrote:
I'd prefer to be pointed at some documents which describe exactly the wrokflow to sign a package with makepkg, upload it, add it to a db, update, replace and delete it.
Once there is a version of pacman which supports signed packages I can start implementing these ideas.
I think it is best not to wait for pacman - that is what is stopping this from reaching usable reality. From the looks of it, pacman is never going to get done until the signatures are available and there's a demand for checking them. If changes need to be made later to make the signatures (file format, etc) compatible with pacman, that should be minor, especially if it is well written. As I said, I'm eager to write and maintain a script that checks the pkg cache signatures, at least until pacman is complete in this area, and I don't mind if the sig db format changes a few times. But I can't check signatures when there are none to check. So I definitely encourage the work you're talking about, and it alone will vastly improve the security situation, regardless of pacman.
On 19/02/11 19:25, Pierre Schmitz wrote:
On Sat, 19 Feb 2011 17:35:21 +1000, Allan McRae wrote:
I will repeat myself again... Patches for pacman do bugger all for getting signatures into Arch Linux repos. Patches for the Arch Linux devtools/db-scripts packages are needed.
To be honest, I don't think it's worth to work on patches for devtools dbscripts right now. I'd prefer to be pointed at some documents which describe exactly the wrokflow to sign a package with makepkg, upload it, add it to a db, update, replace and delete it.
Once there is a version of pacman which supports signed packages I can start implementing these ideas.
All there is from a pacman point of view is this: 1) makepkg signs the package with the packagers key and creates a detached signature 2) repo-add adds that key to the repo db 3) pacman has a local keyring to verify the package signatures against. An addition is repo-add will verify its current signature and resign the database after adding the package(s). So for a start, we could have the commitpkg just uploading signature files alongside packages. It could also be temporarily responsible for signing the package until makepkg with signing support gets released, or perhaps better that could be done by makechrootpkg...
And last but not least we need to think about key management which is less technical but very important.
I think that is fairly separate to the pacman implementation. Getting some sort of ultimate trust key (or equivalent) into the pacman keyring is the most difficult part. Then a distro can provide a pacman-keyring package signed by that key which will provide the developer keys. The pacman-key tool (a useful wrapper to gpg) is then used to import those keys into the pacman keyring. How the keys are signed in order to for a useful web of trust is up to the distro. Allan
Hi Allan
I will repeat myself again... Patches for pacman do bugger all for getting signatures into Arch Linux repos. Patches for the Arch Linux devtools/db-scripts packages are needed.
Well, Pierre says the same for pacman. Someone has to take the first initiative here.
And I will once again point to the package signing TODO page for a list of what we need to do at a minimum before this becomes integrated in the main pacman branch: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing As with all feature branches, they integrated into master when they are finished. Otherwise we can not make a release without actually getting it fully completed or backing out the unfinished work. Given the rate this has been developed, the second seems the likely outcome.
I understand that it should be finished before it is merged. What is missing is a strong statement from the development team that they want signatures asap. I think there are enough people who are willing to provide patches (me included) if you show real interest in package signing.
Finally, "minor" performance issues interest me a hell of a lot more than package signing. Mainly because that actually affects me whereas unsigned packages really does not... That is why I spent my free time implementing them. Thinking about it, improving optdepends handling, transaction hooks, VCS support in makepkg, adding a test suite for makepkg, automatic creation of debug packages, .... all affect me more than package signing does, so I maybe will start work on package signing again once those are finished.
You really have to rethink your priority list here. Those attacks on package managers are known for a long time and the package signing point has come up very often on the pacman mailing list. So there are people who are concerned about it. Daniel
On 19/02/11 22:55, Daniel Mendler wrote:
Hi Allan
I will repeat myself again... Patches for pacman do bugger all for getting signatures into Arch Linux repos. Patches for the Arch Linux devtools/db-scripts packages are needed.
Well, Pierre says the same for pacman. Someone has to take the first initiative here.
Well, he is wrong... :P I will post why in reply to that message soon.
And I will once again point to the package signing TODO page for a list of what we need to do at a minimum before this becomes integrated in the main pacman branch: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing As with all feature branches, they integrated into master when they are finished. Otherwise we can not make a release without actually getting it fully completed or backing out the unfinished work. Given the rate this has been developed, the second seems the likely outcome.
I understand that it should be finished before it is merged. What is missing is a strong statement from the development team that they want signatures asap. I think there are enough people who are willing to provide patches (me included) if you show real interest in package signing.
What a load of bullshit. The first patch was submitted over two years ago and immediately pulled into a branch. But as has happened repeatedly, that person disappeared and never finished. All further work by other people was also reviewed and/or pulled to one of the main developers git branches fairly quickly after posting. And we have repeatedly said "patches welcome". I'm not sure how much clearer we could be that this is an area that we would be happy for people to work on.
Finally, "minor" performance issues interest me a hell of a lot more than package signing. Mainly because that actually affects me whereas unsigned packages really does not... That is why I spent my free time implementing them. Thinking about it, improving optdepends handling, transaction hooks, VCS support in makepkg, adding a test suite for makepkg, automatic creation of debug packages, .... all affect me more than package signing does, so I maybe will start work on package signing again once those are finished.
You really have to rethink your priority list here. Those attacks on package managers are known for a long time and the package signing point has come up very often on the pacman mailing list. So there are people who are concerned about it.
As I said, it really does not affect me. I use the master server for my repo db downloads and know exactly which package updates to expect given I see all commits to our svn repos. So the scope in which I could be attacked is very small and I am prepared to take that risk. So my priorities are clearly different to other peoples. The key difference is, I submit patches to implement what I consider a priority... Allan
On Sat, 19 Feb 2011 12:38:07 +1000 Allan McRae <allan@archlinux.org> wrote:
It makes absolutely no sense to have pacman manually fork a process to run gpg to verify a package/database and then manually parse the output when the upstream gpg developers provide a library to do just that.
Perhaps if you look at it from a different perspective, it will make sense to you. This is what I meant by code efficiency not always being optimum in security dev. I still think you've already precluded another solution, but I'll see if I can enlighten you on what I'm getting at. If pacman forks a call to gpg using a command line, it is transparent. I can replace gpg with a script and catch the call, examine it, log it, even alter the text stream returned to see how pacman reacts. I can do this on an executable of unknown origin and with possibly tampered source, without needed the source. I can even use a custom gpg or wrapper script to do other things you and I aren't able to anticipate right now - it is open-ended. The interprocess communication is open, flexible, and transparent. That is why linux programs operate on the command line and on text streams - it makes for transparency and flexibility. Check out http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosop... In particular, ponder how these might apply, doubly so in security: 4. Choose portability over efficiency. 5. Store data in flat text files. 6. Use shell scripts to increase leverage and portability. 8. Avoid captive user interfaces. 9. Make every program a filter. And especially: 1a. Allow the user to tailor the environment. In addition, if I want to sabotage the source, API calls make for easy hiding of changes that may not be detected, whereas changing command line usage makes a lot of noise and can be detected. Will you notice one value changed in 10,000 lines to create a buffer overrun where I can later inject traceless code? Probably not. In sophisticated security breaches, that's how things are done. They're 'accidents' which can later be denied if discovered. Let's see you deny changing the keyring used on the command line. That's just a small sample of why open and flexible interprocess communication is valuable in security dev. That's not to say it's always done this way - far from it, sometimes with ulterior motives.
Finally, "minor" performance issues interest me a hell of a lot more than package signing.
Obvious Allan, you don't understand the importance of package signing and with that poor attitude and lack of awareness I don't think you should be working on security at all. All you're apparently doing is sabotaging it by procrastinating. Obviously you're the type that needs to see a huge security breach in Arch to understand the importance of this. And even without a huge breach, unsigned packages create a local lack of security for admins. Which part of this aren't you getting? Why do you think Microsoft bothers to sign their updates? Just for the heck of it? (Sad that in this case Microsoft is being used as an example of good security practice - that's how out of line Arch's package security is.) It's great when one of the devs responsible for package signing announces he doesn't care about package signing, it's just stupid. Very professional. I'll not be contracting your services, thanks.
I found it really annoying to not be able to disable/enable signing from the command line.
While I might agree, you seem to find this whole package security subject "really annoying" and too much trouble to bother with. I find a disconcerting lack of good security practices in Arch, and I'm beginning to see why.
But to be the guy who "makes things work", patches will be required.
Interesting that you think so, because patches are the way to make non-secure junk. The way to make things work is for the person most familiar with the code and protocols to make those changes rather than him begging others to write ill-fitting patches. Patches are also a big waste of time because what someone familiar with the code can do in a few minutes (and do well) may take hours of research for someone unfamiliar (to do poorly). Talk about efficiency - try applying it to your work in larger ways. Maybe that's one reason why it takes you so long to develop - you're unwilling to take on responsibility for the project as a whole. You definitely seem a very reluctant and whining freeware developer. Get over yourself and put some quality into your work, regardless of what you're paid or not paid. Or don't - in which case you're not worth your complaining.
On 19/02/11 23:06, IgnorantGuru wrote:
On Sat, 19 Feb 2011 12:38:07 +1000 Allan McRae<allan@archlinux.org> wrote:
It makes absolutely no sense to have pacman manually fork a process to run gpg to verify a package/database and then manually parse the output when the upstream gpg developers provide a library to do just that.
Perhaps if you look at it from a different perspective, it will make sense to you. This is what I meant by code efficiency not always being optimum in security dev. I still think you've already precluded another solution, but I'll see if I can enlighten you on what I'm getting at.
If pacman forks a call to gpg using a command line, it is transparent. I can replace gpg with a script and catch the call, examine it, log it, even alter the text stream returned to see how pacman reacts. I can do this on an executable of unknown origin and with possibly tampered source, without needed the source. I can even use a custom gpg or wrapper script to do other things you and I aren't able to anticipate right now - it is open-ended. The interprocess communication is open, flexible, and transparent. That is why linux programs operate on the command line and on text streams - it makes for transparency and flexibility.
Check out http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosop... In particular, ponder how these might apply, doubly so in security: 4. Choose portability over efficiency. 5. Store data in flat text files. 6. Use shell scripts to increase leverage and portability. 8. Avoid captive user interfaces. 9. Make every program a filter.
And especially: 1a. Allow the user to tailor the environment.
In addition, if I want to sabotage the source, API calls make for easy hiding of changes that may not be detected, whereas changing command line usage makes a lot of noise and can be detected. Will you notice one value changed in 10,000 lines to create a buffer overrun where I can later inject traceless code? Probably not. In sophisticated security breaches, that's how things are done. They're 'accidents' which can later be denied if discovered. Let's see you deny changing the keyring used on the command line.
That's just a small sample of why open and flexible interprocess communication is valuable in security dev. That's not to say it's always done this way - far from it, sometimes with ulterior motives.
Or is it less secure to write our own code (reviewed by perhaps two people total) to launch and parse the output of gpg or use the wrapper provided by the gpgp devs. Note that gpgme just calls gpg, so you can still replace that with a wrapper and do everything you just pointed out.
Finally, "minor" performance issues interest me a hell of a lot more than package signing.
Obvious Allan, you don't understand the importance of package signing and with that poor attitude and lack of awareness I don't think you should be working on security at all. All you're apparently doing is sabotaging it by procrastinating. Obviously you're the type that needs to see a huge security breach in Arch to understand the importance of this. And even without a huge breach, unsigned packages create a local lack of security for admins. Which part of this aren't you getting? Why do you think Microsoft bothers to sign their updates? Just for the heck of it? (Sad that in this case Microsoft is being used as an example of good security practice - that's how out of line Arch's package security is.)
1) I understand its importance, that is different from it interesting me 2) I am not "working" on anything. I am volunteering my time. 3) I am not sabotaging anything. I have reviewed all patches submitted here for package signing and have pulled them to a git repo and even spent time fixing the current implementation.
It's great when one of the devs responsible for package signing announces he doesn't care about package signing, it's just stupid. Very professional. I'll not be contracting your services, thanks.
Firstly, I am responsible for nothing. I only choose to pull together the package signing patches in my spare time. Strangely enough, contracting my services would actually motivate me to implement this. My standard consultancy rate is USD1000 per day or part thereof.
I found it really annoying to not be able to disable/enable signing from the command line.
While I might agree, you seem to find this whole package security subject "really annoying" and too much trouble to bother with.
No, I just find it not very interesting.
I find a disconcerting lack of good security practices in Arch, and I'm beginning to see why.
But to be the guy who "makes things work", patches will be required.
Interesting that you think so, because patches are the way to make non-secure junk. The way to make things work is for the person most familiar with the code and protocols to make those changes rather than him begging others to write ill-fitting patches. Patches are also a big waste of time because what someone familiar with the code can do in a few minutes (and do well) may take hours of research for someone unfamiliar (to do poorly). Talk about efficiency - try applying it to your work in larger ways. Maybe that's one reason why it takes you so long to develop - you're unwilling to take on responsibility for the project as a whole. You definitely seem a very reluctant and whining freeware developer. Get over yourself and put some quality into your work, regardless of what you're paid or not paid. Or don't - in which case you're not worth your complaining.
I'm not complaining. If I was complaining, I would provide patches. Note that I only began looking at the actual pacman code in the last few months when I saw a way to improve the backend and instead of writing long abusive emails about it, I got coding. Until then I only dealt with makepkg. And guess what features will be in the next pacman release... See how this works? Patches are needed or it does not get implemented. Yes it will take someone familiar with that section of the code less time (and I am probably still not that person). But that makes an assumption that the person who know the code 1) has time to implement this and 2) cares to spend that time implementing this. Obviously, that is not the case or we would have package signing implemented by now. So we need people who satifiy criteria 1) and 2) to submit patches. Allan
On Sat, 19 Feb 2011 23:46:57 +1000 Allan McRae <allan@archlinux.org> wrote:
Or is it less secure to write our own code (reviewed by perhaps two people total) to launch and parse the output of gpg or use the wrapper provided by the gpgp devs. Note that gpgme just calls gpg, so you can still replace that with a wrapper and do everything you just pointed out.
I actually don't have huge problems with gpgme, but you said you couldn't understand my point, so I explained. Based on what I have seen over the years, I still think parsing the text is wiser. Anything which makes security mechanisms more transparent improves security, in general. But I understand why APIs are so inviting (to developers and hackers alike).
1) I understand its importance
I don't believe so, or you would give it higher priority. Apparently we need a hacker to exploit this and inconvenience huge numbers of people for YOU to see the importance, Microsoft-style, but that's a very lazy and irresponsible approach.
2) I am not "working" on anything. I am volunteering my time.
I find that a poor attitude, as I've always considered freeware (and other volunteer WORK) among the most important WORK I do, but obviously you've got some issues about developing freeware. If you're that miserable, don't do it. A bitter baker bakes a bitter bread. You're taking the joy out of development with your approach IMO. One of the joys of being a freeware developer is that you're free. Turning it into an obligation that you whine about is missing the joy of it. So like I said, if you're that miserable, don't do it - no one is going to make your misery worth it by paying you $1000 for this, like in your 'real work'.
3) I am not sabotaging anything. I have reviewed all patches submitted here for package signing and have pulled them to a git repo and even spent time fixing the current implementation.
I do acknowledge that you've brought this forward a bit, but your attitude about your _work_ gives me great cause for concern. When you work with any area of cryptography, remember that lives and certainly livelihoods can literally depend on your keystrokes (even though you may not want or expect them to), so get behind your work or don't do it. This isn't just a toy, free though it may be.
On 20/02/11 00:33, IgnorantGuru wrote:
On Sat, 19 Feb 2011 23:46:57 +1000 Allan McRae<allan@archlinux.org> wrote:
Or is it less secure to write our own code (reviewed by perhaps two people total) to launch and parse the output of gpg or use the wrapper provided by the gpgp devs. Note that gpgme just calls gpg, so you can still replace that with a wrapper and do everything you just pointed out.
I actually don't have huge problems with gpgme, but you said you couldn't understand my point, so I explained. Based on what I have seen over the years, I still think parsing the text is wiser. Anything which makes security mechanisms more transparent improves security, in general. But I understand why APIs are so inviting (to developers and hackers alike).
1) I understand its importance
I don't believe so, or you would give it higher priority. Apparently we need a hacker to exploit this and inconvenience huge numbers of people for YOU to see the importance, Microsoft-style, but that's a very lazy and irresponsible approach.
Let me rephrase that: I understand its importance _to other people_. As I have said, this whole issue does not particularly affect me so I give it low priority. I really do not care if it affects others. I develop pacman and Arch Linux to improve my computing experience. If others get benefit from my work, then that is a bonus.
2) I am not "working" on anything. I am volunteering my time.
I find that a poor attitude, as I've always considered freeware (and other volunteer WORK) among the most important WORK I do, but obviously you've got some issues about developing freeware. If you're that miserable, don't do it. A bitter baker bakes a bitter bread. You're taking the joy out of development with your approach IMO. One of the joys of being a freeware developer is that you're free. Turning it into an obligation that you whine about is missing the joy of it. So like I said, if you're that miserable, don't do it - no one is going to make your misery worth it by paying you $1000 for this, like in your 'real work'.
I think we have just agreed... in a way. I should focus on the areas that make me a happy contributor. If that does not happen to be package signing, then so be it.
3) I am not sabotaging anything. I have reviewed all patches submitted here for package signing and have pulled them to a git repo and even spent time fixing the current implementation.
I do acknowledge that you've brought this forward a bit, but your attitude about your _work_ gives me great cause for concern. When you work with any area of cryptography, remember that lives and certainly livelihoods can literally depend on your keystrokes (even though you may not want or expect them to), so get behind your work or don't do it. This isn't just a toy, free though it may be.
I think I know every distribution using pacman as a package manager and (unless there is an enterprise level distro I am missing) if peoples lives depend on one of these distros, then I am sorry to say it but in my opinion they are stupid and deserve to die. Allan
On Sun 20 Feb 2011 01:24 +1000, Allan McRae wrote:
On 20/02/11 00:33, IgnorantGuru wrote:
On Sat, 19 Feb 2011 23:46:57 +1000 Allan McRae<allan@archlinux.org> wrote:
Or is it less secure to write our own code (reviewed by perhaps two people total) to launch and parse the output of gpg or use the wrapper provided by the gpgp devs. Note that gpgme just calls gpg, so you can still replace that with a wrapper and do everything you just pointed out.
I actually don't have huge problems with gpgme, but you said you couldn't understand my point, so I explained. Based on what I have seen over the years, I still think parsing the text is wiser. Anything which makes security mechanisms more transparent improves security, in general. But I understand why APIs are so inviting (to developers and hackers alike).
1) I understand its importance
I don't believe so, or you would give it higher priority. Apparently we need a hacker to exploit this and inconvenience huge numbers of people for YOU to see the importance, Microsoft-style, but that's a very lazy and irresponsible approach.
Let me rephrase that: I understand its importance _to other people_.
As I have said, this whole issue does not particularly affect me so I give it low priority. I really do not care if it affects others. I develop pacman and Arch Linux to improve my computing experience. If others get benefit from my work, then that is a bonus.
2) I am not "working" on anything. I am volunteering my time.
I find that a poor attitude, as I've always considered freeware (and other volunteer WORK) among the most important WORK I do, but obviously you've got some issues about developing freeware. If you're that miserable, don't do it. A bitter baker bakes a bitter bread. You're taking the joy out of development with your approach IMO. One of the joys of being a freeware developer is that you're free. Turning it into an obligation that you whine about is missing the joy of it. So like I said, if you're that miserable, don't do it - no one is going to make your misery worth it by paying you $1000 for this, like in your 'real work'.
I think we have just agreed... in a way. I should focus on the areas that make me a happy contributor. If that does not happen to be package signing, then so be it.
3) I am not sabotaging anything. I have reviewed all patches submitted here for package signing and have pulled them to a git repo and even spent time fixing the current implementation.
I do acknowledge that you've brought this forward a bit, but your attitude about your _work_ gives me great cause for concern. When you work with any area of cryptography, remember that lives and certainly livelihoods can literally depend on your keystrokes (even though you may not want or expect them to), so get behind your work or don't do it. This isn't just a toy, free though it may be.
I think I know every distribution using pacman as a package manager and (unless there is an enterprise level distro I am missing) if peoples lives depend on one of these distros, then I am sorry to say it but in my opinion they are stupid and deserve to die.
Yeah! Archers deserve to die! But really I'm not convinced by this hyper-paranoia trash. There will always be ways to compromise your machine. Someone who would go through the trouble of setting up a proxy mirror and injecting malicious code into seemingly normal packages is probably going to find other ways. Package signing will not protect you. You will never be safe. The truth is out there.
Yeah! Archers deserve to die!
But really I'm not convinced by this hyper-paranoia trash. There will always be ways to compromise your machine. Someone who would go through the trouble of setting up a proxy mirror and injecting malicious code into seemingly normal packages is probably going to find other ways. Package signing will not protect you.
You will never be safe. The truth is out there. This is opensource - if you would create real trouble, just help with kernel- modules. ;) The only difference is, in other distributions these errors came through your system signed.
Why hacking, when simple development is so easy?
On Sat, 2011-02-19 at 20:05 +0100, Alf Gaida wrote:
Yeah! Archers deserve to die!
But really I'm not convinced by this hyper-paranoia trash. There will always be ways to compromise your machine. Someone who would go through the trouble of setting up a proxy mirror and injecting malicious code into seemingly normal packages is probably going to find other ways. Package signing will not protect you.
You will never be safe. The truth is out there. This is opensource - if you would create real trouble, just help with kernel- modules. ;) The only difference is, in other distributions these errors came through your system signed.
Why hacking, when simple development is so easy?
I don't understand what you are saying, but in short. You can't force Allan / any pacman-dev to create package signing for pacman. If you really want to get this feature into pacman/archlinux (dbscripts etc. needs to be redone too): -read the code -add patches -wait for devs to sign them off on a side note: http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_speed_high_securi... -- Jelle van der Waa
Maybe i have should use a <ironic> tag. Nothing is secure in the end, if anyone will do harm, he'll find a security hole. Like this: http://www.webhostingtalk.com/showthread.php?t=717240 I agree fully with Allan. For me it makes not a big difference if a package is signed or not. It's a nice to have feature and i would be glad if someone would implement it. But for me it has a very low priority.. The performance issues addressed by Allan are much more importent for me, but unfortunally in the moment i'm not so in the code that i could really help.
On 02/19/2011 08:38 PM, Alf Gaida wrote:
Maybe i have should use a <ironic> tag. Nothing is secure in the end, if anyone will do harm, he'll find a security hole. Like this: http://www.webhostingtalk.com/showthread.php?t=717240
Exactly, because we cannot reach perfect security, we should not care about it at all!
I agree fully with Allan. For me it makes not a big difference if a package is signed or not. It's a nice to have feature and i would be glad if someone would implement it. But for me it has a very low priority..
It makes a big difference if your system is compromised. And then you will care about it. I don't understand this naive and short-sighted opinion. @Allan: I am a bit disappointed with your opinion that you want to implement only features that you care about. I think there is also a reponsibility if you are one of the main developers of the package manager of a popular distribution. And you don't even have to implement the features yourself - there are people who are willing to help. But those people should also get some support by you. Daniel
On 20/02/11 08:42, Daniel Mendler wrote:
@Allan: I am a bit disappointed with your opinion that you want to implement only features that you care about. I think there is also a reponsibility if you are one of the main developers of the package manager of a popular distribution. And you don't even have to implement the features yourself - there are people who are willing to help. But those people should also get some support by you.
Those people get full support from me. You might have seen between these emails that I reviewed the three patches for package signing posted to this list yesterday within 12 hours of them being posted. I am serious when I say "patches welcome". I just turns out those people that claim to be willing to help, rare do anything. Allan
I'm not sure I even want to get involved in this thread. :/ On Sat, Feb 19, 2011 at 5:05 PM, Allan McRae <allan@archlinux.org> wrote:
On 20/02/11 08:42, Daniel Mendler wrote:
@Allan: I am a bit disappointed with your opinion that you want to implement only features that you care about. I think there is also a reponsibility if you are one of the main developers of the package manager of a popular distribution.
This is totally false. None of us signed up because we wanted to code stuff other people wanted; we saw an open source project we could contribute to and all the sudden we ended up being the lead developers. If our fellow developers were telling us "hey we really need package signing", we'd probably set aside our having fun to work on it a bit more, but if you notice, none of them are doing that.
Responsibility? I take responsibility for myself and no one else, anything else would be stupid and make me legally liable for work I don't even get paid for.
And you don't even have to implement the features yourself - there are people who are willing to help. But those people should also get some support by you.
Those people get full support from me. You might have seen between these emails that I reviewed the three patches for package signing posted to this list yesterday within 12 hours of them being posted.
I am serious when I say "patches welcome". I just turns out those people that claim to be willing to help, rare do anything. The other thing we frequently see is work that doesn't come close to meeting our standards, and when we point this out, we get accused of not wanting to implement package signing. At that point, what are we expected to do? Redo the work ourself?
Either way, can we all just relax a bit? This thread is becoming a bitching ground, and nothing productive has come out of it. Act civil and stop using the guise of the internet to say anything you want and attack others. It really isn't appropriate. -Dan
Responsibility? I take responsibility for myself and no one else, anything else would be stupid and make me legally liable for work I don't even get paid for.
I don't mean that you take legal reponsibility. I only mean that you have some influence one how this project continues.
And you don't even have to implement the features yourself - there are people who are willing to help. But those people should also get some support by you.
Those people get full support from me. You might have seen between these emails that I reviewed the three patches for package signing posted to this list yesterday within 12 hours of them being posted.
I am serious when I say "patches welcome". I just turns out those people that claim to be willing to help, rare do anything. The other thing we frequently see is work that doesn't come close to meeting our standards, and when we point this out, we get accused of not wanting to implement package signing. At that point, what are we expected to do? Redo the work ourself?
I understand that the code quality should meet the quality standards. And I understand that you don't want to redo the work yourself if this is not the case. This is totally acceptable.
Either way, can we all just relax a bit? This thread is becoming a bitching ground, and nothing productive has come out of it. Act civil and stop using the guise of the internet to say anything you want and attack others. It really isn't appropriate.
I think this should also go to a much more technical level. We have the gpg tree in Allan's repository. As I said I tested it with a repository and got it to work. So can you tell me what do you need till this can be merged into master? 1. Design a strategy to manage the keyrings and adapt the tools to it 2. Patches for the issues on the Package Signining Wiki Page 3. Patches to db-scripts to manage the database with gpg signatures Some of the issues on the wiki page are really minor (e.g. rename option). There are more complex ones (replacing verified db with unverified one, reworking the signature checking code when using pacman -U). And there are already patches for some of the issues. So what do you say about the code quality of the branch? It it acceptable at this point or is there improvement needed? Are there other blockers preventing you from merging it as soon as the points above are solved? Daniel
On 20/02/11 10:36, Daniel Mendler wrote:
I think this should also go to a much more technical level. We have the gpg tree in Allan's repository. As I said I tested it with a repository and got it to work. So can you tell me what do you need till this can be merged into master?
1. Design a strategy to manage the keyrings and adapt the tools to it 2. Patches for the issues on the Package Signining Wiki Page 3. Patches to db-scripts to manage the database with gpg signatures
Some of the issues on the wiki page are really minor (e.g. rename option). There are more complex ones (replacing verified db with unverified one, reworking the signature checking code when using pacman -U). And there are already patches for some of the issues.
So what do you say about the code quality of the branch? It it acceptable at this point or is there improvement needed? Are there other blockers preventing you from merging it as soon as the points above are solved?
As far as I am concerned, the major points on the TODO list that need patches are the first five for pacman: TODO: fix (and refactor) reading signatures for packages installed with -U TODO: have a way to force a signature check with -U (i.e. abort if no signature is found) TODO: only replace old database when signature is valid TODO: output when downloading signature file - name when downloaded TODO: output when downloading signature file - "error" when not available The other issues are all fairly minor (and the pacman-key/makepkg ones mostly have patches that just need revised already). So if patches are submitted for those five points, and any criticism followed up, I will commit to then spending the time doing the needed tidying/rebasing of the code on my gpg branch to have it suitable for merging. Allan
Hi Allan
As far as I am concerned, the major points on the TODO list that need patches are the first five for pacman:
TODO: fix (and refactor) reading signatures for packages installed with -U TODO: have a way to force a signature check with -U (i.e. abort if no signature is found) TODO: only replace old database when signature is valid TODO: output when downloading signature file - name when downloaded TODO: output when downloading signature file - "error" when not available
I have a patch for the third point. Can you please clarify the last two points? Do you think the output is too verbose (two download progress bars with the same name etc, and two error messages in case of error)?
The other issues are all fairly minor (and the pacman-key/makepkg ones mostly have patches that just need revised already).
I took a look on the other patches. I agree that these need only reviewing and merging.
So if patches are submitted for those five points, and any criticism followed up, I will commit to then spending the time doing the needed tidying/rebasing of the code on my gpg branch to have it suitable for merging.
Sounds good. Daniel
On 20/02/11 21:47, Daniel Mendler wrote:
Hi Allan
As far as I am concerned, the major points on the TODO list that need patches are the first five for pacman:
TODO: fix (and refactor) reading signatures for packages installed with -U TODO: have a way to force a signature check with -U (i.e. abort if no signature is found) TODO: only replace old database when signature is valid TODO: output when downloading signature file - name when downloaded TODO: output when downloading signature file - "error" when not available
I have a patch for the third point. Can you please clarify the last two points? Do you think the output is too verbose (two download progress bars with the same name etc, and two error messages in case of error)?
Some examples of what those last two points cover: 1) VerifySig = Always, valid signature: :: Synchronizing package databases... pacman 1.0K 381.6K/s 00:00:00 [######################] 100% pacman 0.3K 14.4M/s 00:00:00 [######################] 100% kernel64 1.5K 42.2M/s 00:00:00 [######################] 100% Two download bars with the same name - the second should be something like pacman.sig 2) VerifySig = Always, no signature available: :: Synchronizing package databases... pacman 1.0K 317.1K/s 00:00:00 [######################] 100% error: failed retrieving file 'pacman.db.sig' from disk : No such file or directory error: Failed to download signature for db: No such file or directory error: failed to update pacman (invalid PGP signature) kernel64 1.5K 55.1M/s 00:00:00 [######################] 100% The error messages need reduced to a possibly single, clear message 3) VerifySig = Optional, no signature available: :: Synchronizing package databases... pacman 1.0K 363.2K/s 00:00:00 [######################] 100% error: failed retrieving file 'pacman.db.sig' from disk : No such file or directory kernel64 1.5K 30.5M/s 00:00:00 [######################] 100% That is not an actual error as signature checking is optional
It makes a big difference if your system is compromised. And then you will care about it. I don't understand this naive and short-sighted opinion.
Daniel I'm _not_ naive and short-sighted. i just don't care. If i were concernd about
Am 19. Feb. 11, 23:42:18 schrieb Daniel Mendler: this there will be only two ways to go: Don't use arch and anythig pacman- related or implement it by myself. So my descision is: I use arch and don't implement it. If i had the time, the knowledge and the interest to do so i would. I'm not interested in.
On Sat, Feb 19, 2011 at 2:06 PM, IgnorantGuru <jgj7.pacmandev@mailnull.com> wrote:
Interesting that you think so, because patches are the way to make non-secure junk. The way to make things work is for the person most familiar with the code and protocols to make those changes rather than him begging others to write ill-fitting patches. Patches are also a big waste of time because what someone familiar with the code can do in a few minutes (and do well) may take hours of research for someone unfamiliar (to do poorly). Talk about efficiency - try applying it to your work in larger ways. Maybe that's one reason why it takes you so long to develop - you're unwilling to take on responsibility for the project as a whole. You definitely seem a very reluctant and whining freeware developer. Get over yourself and put some quality into your work, regardless of what you're paid or not paid. Or don't - in which case you're not worth your complaining.
What makes you worth ? You are not only complaining, you are also freely attacking people when you have no idea who they are, what they do, and how things work around here. Ah, the joy of internet. I don't know why you felt the need to write so many mails just to say one thing : it would be nice to have signatures on the mirrors already, regardless of what pacman and repo-add support. And well, we agree, so thanks for your quality contribution !
On Sat, 19 Feb 2011 15:33:11 +0100 Xavier Chantry <chantry.xavier@gmail.com> wrote:
And well, we agree, so thanks for your quality contribution !
My pleasure. Frankly, I thought it would be a waste of my time to try to talk to the development team about this, but I made my best effort anyway, and perhaps it made some small difference. Now I'll let you guys get back to work. Thanks for the quality work you're doing.
participants (10)
-
Alf Gaida
-
Allan McRae
-
Dan McGee
-
Daniel Mendler
-
Denis A. Altoé Falqueto
-
IgnorantGuru
-
Jelle van der Waa
-
Loui Chang
-
Pierre Schmitz
-
Xavier Chantry