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

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-16-2010, 10:18 PM
Dimitrios Apostolou
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tue, 15 Jun 2010, Ionuț Bîru wrote:
i found this annoying since, debugging is more harder, i have to download the
resulted package to test it, send it, wait for the pool to come. is a mess


even if my system is compromised, we build our packages in clean chroots.


The workflow won't be changing much using a build server: you build and
rebuild on your own system using a clean chroot, until you are satisfied
with the result. Then you submit PKGBUILD to the build server and forget
about it. 99% of the time the build will be successful, since it uses the
exact same buildchroot you did, the package will be automatically signed
with the arch-wide key stored safely in the server and will be submitted
to the repo. 1% of the time something bad happens in the process and you
get notified by email...


I think the idea of build server is only positive, if we somehow
find the equipment needed. :-)



Dimitris
 
Old 06-16-2010, 11:08 PM
Dimitrios Apostolou
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

Hey, what do you think about this way of verifying packages?

On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:
On another note, an easy but maybe a bit costly way to avoid any MITM
tampering to packages, is serve *.md5 files for every package through a
trusted HTTPS host. Then everyone can query that single host and check if the
package he got from a mirror is safe.


Costs: A little more traffic by serving hash files to everyone plus the cost
of the certificate from a CA. Is the income Arch receives from ads and schwag
enough for such a simple solution?


Let me explain it a bit more:

Pacman downloads package-1.tar.xz from a random mirror.
It then fetches:

https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1

Pacman should then know whether the connection to sums.archlinux.org was
tampered, since the certificate is signed from a CA in ca-bundle.crt. So
if the two hashes match, the package is safe (as safe as the archlinux
server...)


That way any type of file can be verified (packages, db files, PKGBUILDs,
patches etc) provided that its cryptographic hash is in that HTTPS host.
Obviously to be able to verify db files, they need a timestamp appended to
them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the
most difficult part of this proposal.


If too many small files is a problem, maybe the whole db.tar.gz can be
served (at the cost of a higher bandwidth utilisation).



This solution doesn't use package signing nor a web-of-trust. It simply
piggybacks on the tried and true HTTPS mechanism. Primary advantage is
the lack of complexity which makes it easy to understand and implement.



What do you think?
Dimitris
 
Old 06-16-2010, 11:34 PM
Allan McRae
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On 17/06/10 00:48, Guillaume ALAUX wrote:

Are the python scripts in the pacbuild package (apple, strawberry,
queuepackage, waka and uploadpackage) used any more as described in this
page<http://wiki.archlinux.org/index.php/Pacbuild> ? Because some of these
scripts point to the old "current" repository we used years ago. And if I
understand it right, they don't really fit with what you just said.


I have no idea if they were ever actually used... I have been around
for a while now, and I never heard of them.



I guess the current way of building packages involves the devtools package
right?


yes. mkarchroot and makechrootpkg.

Allan
 
Old 06-16-2010, 11:35 PM
Dimitrios Apostolou
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Wed, 16 Jun 2010, Dan McGee wrote:

On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:

Hey, what do you think about this way of verifying packages?

On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:


On another note, an easy but maybe a bit costly way to avoid any MITM
tampering to packages, is serve *.md5 files for every package through a
trusted HTTPS host. Then everyone can query that single host and check if
the package he got from a mirror is safe.

Costs: A little more traffic by serving hash files to everyone plus the
cost of the certificate from a CA. Is the income Arch receives from ads and
schwag enough for such a simple solution?


Let me explain it a bit more:

Pacman downloads package-1.tar.xz from a random mirror.
It then fetches:

https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1

Pacman should then know whether the connection to sums.archlinux.org was
tampered, since the certificate is signed from a CA in ca-bundle.crt. So if
the two hashes match, the package is safe (as safe as the archlinux
server...)

That way any type of file can be verified (packages, db files, PKGBUILDs,
patches etc) provided that its cryptographic hash is in that HTTPS host.
Obviously to be able to verify db files, they need a timestamp appended to
them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the
most difficult part of this proposal.

If too many small files is a problem, maybe the whole db.tar.gz can be
served (at the cost of a higher bandwidth utilisation).


This solution doesn't use package signing nor a web-of-trust. It simply
piggybacks on the tried and true HTTPS mechanism. Primary advantage is the
lack of complexity which makes it easy to understand and implement.


What do you think?


I think that someone could blow this apart. I break in, touch a
package of my choosing without telling anyone, and update the checksum
file. Bam- everyone's systems are fucked and the developers never knew
because you didn't do anything both cryptographically secure and
verifiable, you just added some indirection to the process.


HTTPS is both cryptographically correct and verifiable. The case you
mention is if someone breaks the one end, that must be guarded most.
The danger is there everywhere, on the web-of-trust case someone that
broke into a dev's machine and got the key, can sign anything he wants and
serve it to the user, who would know? On the distro-wide key case, it's
like someone stealing that key, and be able to serve/sign everything.


Here, we don't have a key to keep safe, but a server. So it needs special
attention about who has access and how hashes are submitted (although
HTTPS can secure this process too). But I admit that keeping a server safe
is a bit harder than keys, if that was your point.



Dimitris




-Dan
 
Old 06-17-2010, 06:01 PM
Ananda Samaddar
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Sun, 13 Jun 2010 12:46:09 +0200
Xavier Chantry <chantry.xavier@gmail.com> wrote:
>
> It's all there :
> http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg and
> there :
> http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman
>
> Come back to us when everything is implemented and working
>
> You can also read the last thread :
> http://mailman.archlinux.org/pipermail/arch-general/2010-April/012897.html
> And contact Denis A. Altoé Falqueto about pacman-key and all the rest,
> and maybe Aleksis Jauntēvs too
>
> Basically there is no one leading and coordinating these efforts, just
> various people who pushed it a bit at random time in the past, and got
> quickly de-motivated by the lack of interest from everyone else.

It seems to be actually progressing pretty quickly now and from the
other posts on this subject it looks like we may not have to wait too
long before it's implemented. Keep up the good work developers!

Ananda
 

Thread Tools




All times are GMT. The time now is 05:21 AM.

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