FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 02-19-2011, 12:24 PM
Allan McRae
 
Default Your signature please

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
 
Old 02-19-2011, 12:39 PM
IgnorantGuru
 
Default Your signature please

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.
 
Old 02-19-2011, 12:46 PM
Allan McRae
 
Default Your signature please

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_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
 
Old 02-19-2011, 01:09 PM
Allan McRae
 
Default Your signature please

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
 
Old 02-19-2011, 01:33 PM
Xavier Chantry
 
Default Your signature please

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 !
 
Old 02-19-2011, 01:33 PM
IgnorantGuru
 
Default Your signature please

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.
 
Old 02-19-2011, 01:49 PM
IgnorantGuru
 
Default Your signature please

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.
 
Old 02-19-2011, 02:24 PM
Allan McRae
 
Default Your signature please

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
 
Old 02-19-2011, 05:51 PM
Loui Chang
 
Default Your signature please

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.
 
Old 02-19-2011, 06:05 PM
Alf Gaida
 
Default Your signature please

>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?
 

Thread Tools




All times are GMT. The time now is 10:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org