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-13-2010, 10:46 AM
Xavier Chantry
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Sun, Jun 13, 2010 at 11:38 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
>
> This is the reason why we need package signing for Pacman. ┬*I'm aware
> that some progress has been made and it's being worked on. ┬*Are there
> any updates?
>

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.
 
Old 06-14-2010, 02:23 PM
Denis A. Alto├ę Falqueto
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Sun, Jun 13, 2010 at 7:46 AM, Xavier Chantry
<chantry.xavier@gmail.com> wrote:
> On Sun, Jun 13, 2010 at 11:38 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
>>
>> This is the reason why we need package signing for Pacman. ┬*I'm aware
>> that some progress has been made and it's being worked on. ┬*Are there
>> any updates?
>>
>
> 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.

Yes, it's basically true. I'm ye a little motivated. I just don't have
the time right now to do anything. I think I'll push pacman-key and
some other things to the project on gitorious
(http://gitorious.org/pacman-pkgsig). It is a fork of the sig branch
of Allan's git repository, so that we can test things without the need
to have commit rights on Allan's repo.

Anyway, I'm trying to find some time to work on it as soon as
possible, but I can't promise anything. This is my first time working
with C in a big implementation, so this is other problem to deal with.

And keep in mind that package signing per se will not solve this kind
of problems. Repository database signing is more important for that
solution, but is a problem in the current workflow of Arch developers.

--
-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-15-2010, 01:58 PM
Guillaume ALAUX
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

>How exactly is core and extra database populated?
> Moreover, instead of building all packages in the private PCs of
developers
Packages are not build on developers computers but on build machines as
explained here http://wiki.archlinux.org/index.php/Pacbuild

<http://wiki.archlinux.org/index.php/Pacbuild>There is also an
implementation of package signing in pacman on the link Xavier provided some
emails up on this conversation. I don't think there is any need to re-think
it all. Just need to be tested.

I am currently trying to set up a build system on my box and will then try
to use these patches to provide feedback.

On 15 June 2010 15:57, Dimitrios Apostolou <jimis@gmx.net> wrote:

> On Mon, 14 Jun 2010, Denis A. AltoÚ Falqueto wrote:
>
>> And keep in mind that package signing per se will not solve this kind
>> of problems. Repository database signing is more important for that
>> solution, but is a problem in the current workflow of Arch developers.
>>
>
> How exactly is core and extra database populated?
>
> Moreover, instead of building all packages in the private PCs of
> developers, I think it is preferable to submit PKGBUILDs to build servers
> (via web interface maybe) and let the servers do the build + signing +
> repoupdate... That way if a developer's system gets compromised his packages
> will stay clean. Of course that needs extra work and equipment, but perhaps
> we can agree to it as a future target.
>
> 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?
>
>
> Dimitris
>
 
Old 06-15-2010, 02:04 PM
Denis A. AltoÚ Falqueto
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> On Mon, 14 Jun 2010, Denis A. AltoÚ Falqueto wrote:
>>
>> And keep in mind that package signing per se will not solve this kind
>> of problems. Repository database signing is more important for that
>> solution, but is a problem in the current workflow of Arch developers.
>
> How exactly is core and extra database populated?
>
> Moreover, instead of building all packages in the private PCs of developers,
> I think it is preferable to submit PKGBUILDs to build servers (via web
> interface maybe) and let the servers do the build + signing + repoupdate...
> That way if a developer's system gets compromised his packages will stay
> clean. Of course that needs extra work and equipment, but perhaps we can
> agree to it as a future target.

Well, in fact, that is the very problem we have. The repository
database files are created remotely and I think that we should avoid
signing files remotely. In fact, a dev's machine is less visible than
the servers of Arch. And sse the response from Ionut too.

I was thinking (see the wiki page for details) in a way to break the
creation of the repo db files in two stages. It probably will be
transparent for the developers. One stage creates the db file and the
other signs, but that must be done locally. I think that creating an
MD5 checksum and signing just that can be a solution.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-15-2010, 02:46 PM
Dan McGee
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tue, Jun 15, 2010 at 8:58 AM, Guillaume ALAUX <guillaume@alaux.net> wrote:
>>How exactly is core and extra database populated?
>> Moreover, instead of building all packages in the private PCs of
> developers
> Packages are not build on developers computers but on build machines as
> explained here http://wiki.archlinux.org/index.php/Pacbuild

Pacbuild hasn't been touched for years...

-Dan
 
Old 06-15-2010, 02:58 PM
Guillaume ALAUX
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On 15 June 2010 16:46, Dan McGee <dpmcgee@gmail.com> wrote:

> On Tue, Jun 15, 2010 at 8:58 AM, Guillaume ALAUX <guillaume@alaux.net>
> wrote:
> >>How exactly is core and extra database populated?
> >> Moreover, instead of building all packages in the private PCs of
> > developers
> > Packages are not build on developers computers but on build machines as
> > explained here http://wiki.archlinux.org/index.php/Pacbuild
>
> Pacbuild hasn't been touched for years...
>
> -Dan
>

> Pacbuild hasn't been touched for years...
Yes I have had (and actually still have) some issues setting up the complete
build system but I try to get the wiki page up to date
 
Old 06-15-2010, 03:02 PM
Guillaume ALAUX
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On 15 June 2010 16:55, Dimitrios Apostolou <jimis@gmx.net> wrote:

> On Tue, 15 Jun 2010, Denis A. AltoÚ Falqueto wrote:
>
>> On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net>
>> wrote:
>>
>>> Moreover, instead of building all packages in the private PCs of
>>> developers,
>>> I think it is preferable to submit PKGBUILDs to build servers (via web
>>> interface maybe) and let the servers do the build + signing +
>>> repoupdate...
>>> That way if a developer's system gets compromised his packages will stay
>>> clean. Of course that needs extra work and equipment, but perhaps we can
>>> agree to it as a future target.
>>>
>>
>> Well, in fact, that is the very problem we have. The repository
>> database files are created remotely and I think that we should avoid
>> signing files remotely. In fact, a dev's machine is less visible than
>> the servers of Arch. And sse the response from Ionut too.
>>
>
> Let me just clarify here that by "build server" I mean a machine where
> developers have *not* shell access (and in fact almost nobody has), and by
> "package signing" I mean signing with a specific archlinux key which is
> unknown (the private part) to most devs. Some distros follow that approach
> to security.
>
> What you are proposing is package signing by developer keys, that's a
> different approach. I am just bringing up alternatives.
>
>
> Dimitris
>
>
> BTW I don't think that building inside a compromised system is in any way
> secure, even if building inside a chroot.
>

> I think that we should avoid signing files remotely.
Is there any precise reason? If it is because "that remote place could be
compromised" well any dev computer could be compromized too !

> by "package signing" I mean signing with a specific archlinux key which is
unknown (the private part) to most devs.
This is what is implemented in this git
http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg

The diffs I see there (made by Dan and Geoffroy) look good to me. As far as
I understand, when a package is built on the (remote) build server, its
signature is added to the desc file of the repo and the repo.db.tar.gz is
signed itself.
When pacman retreives the repo.db.tar.gz, it checks the signatures of this
file and then has all packages signatures available in it !
This looks very KISS and elegant to me : no mypackage.pkg.tar.xz.asc lying
around in the FTP or (even worse to my opinion) into the pkg tarball.

But if you think about using private/public key authentication for devs when
submitting packages to the build system then I do agree!
 
Old 06-15-2010, 03:34 PM
Denis A. AltoÚ Falqueto
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net> wrote:
>> I think that we should avoid signing files remotely.
> Is there any precise reason? If it is because "that remote place could be
> compromised" well any dev computer could be compromized too !

The main reason is that we would need to keep a copy of the private
key for each sining key in the remote machine. Of course, the private
key is encrypted with the passphrase (a good one, if possible). That
would mitigate an immediate use of a compromised private key, but with
time, it can be cracked and used to sign files on behalf the real
owner of the key. You don't want to let the card of your bank account
on two places, do you? Even though theoretically only you have the
PIN.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-15-2010, 03:47 PM
Denis A. AltoÚ Falqueto
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tue, Jun 15, 2010 at 12:34 PM, Denis A. AltoÚ Falqueto
<denisfalqueto@gmail.com> wrote:
> On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net> wrote:
>>> I think that we should avoid signing files remotely.
>> Is there any precise reason? If it is because "that remote place could be
>> compromised" well any dev computer could be compromized too !
>
> The main reason is that we would need to keep a copy of the private
> key for each sining key in the remote machine. Of course, the private
> key is encrypted with the passphrase (a good one, if possible). That
> would mitigate an immediate use of a compromised private key, but with
> time, it can be cracked and used to sign files on behalf the real
> owner of the key. You don't want to let the card of your bank account
> on two places, do you? Even though theoretically only you have the
> PIN.

Just appending this.

The proposed model is based on the web of trust. We would trust on
some keys to sign other keys. The main keys would be kept by some high
trusty developers. They would sign the public keys of the other
developers (and their personal keys too) with the main ones. We,
mortal users, would trust the main keys to sign the others, and files
signed by the developers' keys would be considered valid, by
transitivity of the trust model.

So, if a developer's key is compromised, it would be enough to
generate another, submit to the key signers and resign the packages
affected. In the current workflow, the package building is made in
chroots, in the machine of each developer (sound reasons given by
Ionut, above). The package would be signed after him testing it. The
package would be upload to a staging area and the repo.db would be
created. At this point, the repo.db should be signed, but exactly how
is the real problem. I have some ideas, as explained in the wiki page,
but I don't have the time and my skills are not so wonderful. This is
done by Debian and Fedora, at least (those were what I've searched.
Others may do it the same way).

And one more thing: the implementation is not the main concern. The
process is. That's why we muse discuss it thoroughly. A good plan will
lead to a good and secure implementation. We should not rush anything.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-15-2010, 04:23 PM
Aleksis Jaunt─ôvs
 
Default Package signing for the umpteenth time (was unrealircd 3.2.8.1-2 contains backdoor)

On Tuesday 15 June 2010 18:47:41 Denis A. Alto├ę Falqueto wrote:
> On Tue, Jun 15, 2010 at 12:34 PM, Denis A. Alto├ę Falqueto
>
> <denisfalqueto@gmail.com> wrote:
> > On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net>
wrote:
> >>> I think that we should avoid signing files remotely.
> >>
> >> Is there any precise reason? If it is because "that remote place could
> >> be compromised" well any dev computer could be compromized too !
> >
> > The main reason is that we would need to keep a copy of the private
> > key for each sining key in the remote machine. Of course, the private
> > key is encrypted with the passphrase (a good one, if possible). That
> > would mitigate an immediate use of a compromised private key, but with
> > time, it can be cracked and used to sign files on behalf the real
> > owner of the key. You don't want to let the card of your bank account
> > on two places, do you? Even though theoretically only you have the
> > PIN.
>
> Just appending this.
>
> The proposed model is based on the web of trust. We would trust on
> some keys to sign other keys. The main keys would be kept by some high
> trusty developers. They would sign the public keys of the other
> developers (and their personal keys too) with the main ones. We,
> mortal users, would trust the main keys to sign the others, and files
> signed by the developers' keys would be considered valid, by
> transitivity of the trust model.
>
> So, if a developer's key is compromised, it would be enough to
> generate another, submit to the key signers and resign the packages
> affected. In the current workflow, the package building is made in
> chroots, in the machine of each developer (sound reasons given by
> Ionut, above). The package would be signed after him testing it. The
> package would be upload to a staging area and the repo.db would be
> created. At this point, the repo.db should be signed, but exactly how
> is the real problem. I have some ideas, as explained in the wiki page,
> but I don't have the time and my skills are not so wonderful. This is
> done by Debian and Fedora, at least (those were what I've searched.
> Others may do it the same way).

I dont think that repo.db should be signed and it is enough to sign only the
packages. As I understand so far the only reason to sign repo.db file is to
prevent "replay" situations in repos.

Maybe it is possible to avoid this by comparing repo.db's between enabled
repos in the mirrorlist when doing db sync. Ofcourse the status between repos
is not consistent all the time but the situation should be ok if the repos are
stable and mantained. If the core.db files does not match then the warning is
issued to the user.

> And one more thing: the implementation is not the main concern. The
> process is. That's why we muse discuss it thoroughly. A good plan will
> lead to a good and secure implementation. We should not rush anything.

I completely agree with this. As someone before said - we can not just throw
some code at people and make them think that everything is secure now.

--
Aleksis Jaunt─ôvs
 

Thread Tools




All times are GMT. The time now is 09:33 AM.

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