[pacman-dev] [ Package Signing ] Your signature please

[Allan McRae]

On 19/02/11 23:06, IgnorantGuru wrote:
> On Sat, 19 Feb 2011 12:38:07 +1000
> Allan McRae<allan at 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_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.
>

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