On 19/02/11 23:06, IgnorantGuru wrote:
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.
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
