On Sat, 19 Feb 2011 12:38:07 +1000 Allan McRae <[email protected]> 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_Philosophy 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.
