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 Pacman Development

 
 
LinkBack Thread Tools
 
Old 06-18-2010, 05:45 PM
Denis A. Altoé Falqueto
 
Default More thought about signature implementation

Hi guys. One more of those long boring emails... sorry.

See this situation: let's say we sign packages and the repo.db and the
signatures are all dettached, in the same directory as their
corresponding files. If some cracker breaks into the machine and
deletes the signatures, pacman will not be able to know if the
packages and repo.db were signed or not. So, it would be necessary to
have some way to indicate that a repository is signed or not and this
information must be kept in such a way that an intruder can't change.

Another factor to consider is that the signature verification should
be optional for each system. I mean, if a user doesn't care about
signatures, he should be able to say "pacman, I can't care less about
signatures, please". So, I believe that the best place for such
information should be in the pacman.conf file, in each repository
section. Maybe one cares about signature in one repository but not for
another. And we would spread the attack surface for the entire user
base, instead of concentrating it only on the server or mirrors.

For the repository update, it would be like this:

1. for each repository
1.1. download the repo.db
1.2. if it is signed
1.2.1. download the signature
1.2.2. check the signature
1.3. extract the db to its right place, as today

For the package verification, it would be like this:

1. downloads the package
2. if the signature is enabled for the repository
2.1. if the package is signed (this information must come from repo.db)
2.1.1. download the signature for the package
2.1.2. checks the signature

For installation of local packages, I am not very worried about
signatures. It could be optional, indicated via parameter.

Well, I think that to store the new information, we'll have to break
the ABI, isn't it? Sorry to say this just a few days after the new
release... Maybe we could have put some new fields to future use.

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

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-19-2010, 03:08 AM
Allan McRae
 
Default More thought about signature implementation

On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:

Hi guys. One more of those long boring emails... sorry.

See this situation: let's say we sign packages and the repo.db and the
signatures are all dettached, in the same directory as their
corresponding files. If some cracker breaks into the machine and
deletes the signatures, pacman will not be able to know if the
packages and repo.db were signed or not. So, it would be necessary to
have some way to indicate that a repository is signed or not and this
information must be kept in such a way that an intruder can't change.


The signatures are currently placed in the repo-db. So only the repo
db needs downloaded and not individual signatures. If an attacker
deletes the repo database and its signature, that is probably the least
of our issues... There will be many copies of a recent signed
database that we can recover all the signatures from.



Another factor to consider is that the signature verification should
be optional for each system. I mean, if a user doesn't care about
signatures, he should be able to say "pacman, I can't care less about
signatures, please". So, I believe that the best place for such
information should be in the pacman.conf file, in each repository
section. Maybe one cares about signature in one repository but not for
another. And we would spread the attack surface for the entire user
base, instead of concentrating it only on the server or mirrors.


I thought that this was already implemented.



For the repository update, it would be like this:

1. for each repository
1.1. download the repo.db
1.2. if it is signed


(and signature checking is enabled for that repo)


1.2.1. download the signature
1.2.2. check the signature
1.3. extract the db to its right place, as today

>

For the package verification, it would be like this:

1. downloads the package
2. if the signature is enabled for the repository
2.1. if the package is signed (this information must come from repo.db)
2.1.1. download the signature for the package


No need for that step. The signature is in repo.db


2.1.2. checks the signature

For installation of local packages, I am not very worried about
signatures. It could be optional, indicated via parameter.


Agreed.


Well, I think that to store the new information, we'll have to break
the ABI, isn't it? Sorry to say this just a few days after the new
release... Maybe we could have put some new fields to future use.


Breaking API happens every major release. It is nothing to be very
concerned about.


Allan
 
Old 06-19-2010, 04:18 AM
Denis A. Altoé Falqueto
 
Default More thought about signature implementation

On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
> On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:
> The signatures are currently placed in the repo-db. * So only the repo db
> needs downloaded and not individual signatures. * If an attacker deletes the
> repo database and its signature, that is probably the least of our issues...
> * *There will be many copies of a recent signed database that we can recover
> all the signatures from.

Hmm, I see. And it is a good idea, indeed.

But I've tested two packages (go-openoffice, 130M, and libxfontcache,
8K) to see how this will affect the final size of the database. The
size of the signatures was 543 bytes each. So the size of the package
will not affect the size of the signatures. What could affect is the
key used, given the hash algorithm is the same. My current key has
2024 bits length The table bellow resume the expected increase for
each repository:

http://pastebin.com/ppfe5dxw

Maybe that is acceptable, maybe not. Thinking about it a little, I
would not be very glad of having to download almost the same
signatures (the ones that didn't change) every time I run pacman -Sy.

I believe that just marking if a package is signed inside the
repository is enough. Or maybe I've misinterpreted something too.

>> Another factor to consider is that the signature verification should
>> be optional for each system. I mean, if a user doesn't care about
>> signatures, he should be able to say "pacman, I can't care less about
>> signatures, please". So, I believe that the best place for such
>> information should be in the pacman.conf file, in each repository
>> section. Maybe one cares about signature in one repository but not for
>> another. And we would spread the attack surface for the entire user
>> base, instead of concentrating it only on the server or mirrors.
>
> I thought that this was already implemented.

Good. I am still getting to know the code.

Thanks for taking the time to answer. I'm already testing pacman-key
and it is working fine. I'll test makepkg and repo-db too, but I
believe they are alright. The changes were very little. I've already
implemented a function to verify the signatures, in C, using popen to
call gpg2. The function was based on a test program I made today, so
it is very probably working, at least the basics.

On a side note, I discovered a funny thing about apt. They don't use
gpgme lib too, but instead call gpgv, a program that just verifies
signatures. Looking through its man paage, I learnt that it doesn't
respect the web of trust of the keyring (!!!). So, in the end, apt
just checks to see if the key is in the keyring (all keys are
trustworthy, according to gpgv's manpage) and verifies the file
signature. I just didn't have a good feeling about it.

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

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-19-2010, 04:40 AM
Allan McRae
 
Default More thought about signature implementation

On 19/06/10 14:18, Denis A. Altoé Falqueto wrote:

On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae<allan@archlinux.org> wrote:

On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:
The signatures are currently placed in the repo-db. So only the repo db
needs downloaded and not individual signatures. If an attacker deletes the
repo database and its signature, that is probably the least of our issues...
There will be many copies of a recent signed database that we can recover
all the signatures from.


Hmm, I see. And it is a good idea, indeed.

But I've tested two packages (go-openoffice, 130M, and libxfontcache,
8K) to see how this will affect the final size of the database. The
size of the signatures was 543 bytes each. So the size of the package
will not affect the size of the signatures. What could affect is the
key used, given the hash algorithm is the same. My current key has
2024 bits length The table bellow resume the expected increase for
each repository:

http://pastebin.com/ppfe5dxw

Maybe that is acceptable, maybe not. Thinking about it a little, I
would not be very glad of having to download almost the same
signatures (the ones that didn't change) every time I run pacman -Sy.


It looks like you just too 543 bytes and multiplied it by the number of
packages. Can we have compressed numbers? You could test this by
making a repo db out of all the packages in your pacman cache using the
current repo-add. Then sign all those packages and make a repo db with
all those signatures using the gpg branch repo-add.


With the next pacman major release, we can switch to .xz compression for
the database which gives up a 30% size decrease to work with.


Allan
 
Old 06-19-2010, 04:51 AM
Denis A. Altoé Falqueto
 
Default More thought about signature implementation

On Sat, Jun 19, 2010 at 1:18 AM, Denis A. Altoé Falqueto
<denisfalqueto@gmail.com> wrote:
> On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
>> On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:
>> The signatures are currently placed in the repo-db. * So only the repo db
>> needs downloaded and not individual signatures. * If an attacker deletes the
>> repo database and its signature, that is probably the least of our issues...
>> * *There will be many copies of a recent signed database that we can recover
>> all the signatures from.
>
> Hmm, I see. And it is a good idea, indeed.
>
> But I've tested two packages (go-openoffice, 130M, and libxfontcache,
> 8K) to see how this will affect the final size of the database. The
> size of the signatures was 543 bytes each. So the size of the package
> will not affect the size of the signatures. What could affect is the
> key used, given the hash algorithm is the same. My current key has
> 2024 bits length The table bellow resume the expected increase for
> each repository:
>
> http://pastebin.com/ppfe5dxw

I've tested with my local cache. It currently contains 808 packages.
i've signed them all and tarred without compression and with gzip,
bzip2 and lzma to see what gives: All the signatures are the same size
(543 bytes each).

tar: 1200 K
tar.gz: 444 K
tar.bz2 425 K
tar.xz: 428 K

Assuming that we'll only store 1/3 of the total size of the
signatures, the new table gets:

http://pastebin.com/BNwd1MAf

The sizes are in KB and the final size of db is the current plus the
size of the compacted signatures. Looking at that table now, it could
be feasible, at least for the user. There'll be an increase in
bandwidth consumption too, because every time someone syncs his
databases, almost the same signatures are being served...

PS: I saw your email while i was writing this, and i'll test makepkg
and repo-add maybe this weekend. Will sure try with my database cache
to see the numbers.

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

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-19-2010, 01:47 PM
Dan McGee
 
Default More thought about signature implementation

On Fri, Jun 18, 2010 at 11:51 PM, Denis A. Altoé Falqueto
<denisfalqueto@gmail.com> wrote:
> On Sat, Jun 19, 2010 at 1:18 AM, Denis A. Altoé Falqueto
> <denisfalqueto@gmail.com> wrote:
>> On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
>>> On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:
>>> The signatures are currently placed in the repo-db. * So only the repo db
>>> needs downloaded and not individual signatures. * If an attacker deletes the
>>> repo database and its signature, that is probably the least of our issues...
>>> * *There will be many copies of a recent signed database that we can recover
>>> all the signatures from.
>>
>> Hmm, I see. And it is a good idea, indeed.
>>
>> But I've tested two packages (go-openoffice, 130M, and libxfontcache,
>> 8K) to see how this will affect the final size of the database. The
>> size of the signatures was 543 bytes each. So the size of the package
>> will not affect the size of the signatures. What could affect is the
>> key used, given the hash algorithm is the same. My current key has
>> 2024 bits length The table bellow resume the expected increase for
>> each repository:
>>
>> http://pastebin.com/ppfe5dxw
>
> I've tested with my local cache. It currently contains 808 packages.
> i've signed them all and tarred without compression and with gzip,
> bzip2 and lzma to see what gives: All the signatures are the same size
> (543 bytes each).
>
> tar: * * * 1200 K
> tar.gz: * * 444 K
> tar.bz2 * *425 K
> tar.xz: * * *428 K
>
> Assuming that we'll only store 1/3 of the total size of the
> signatures, the new table gets:
>
> http://pastebin.com/BNwd1MAf
>
> The sizes are in KB and the final size of db is the current plus the
> size of the compacted signatures. Looking at that table now, it could
> be feasible, at least for the user. There'll be an increase in
> bandwidth consumption too, because every time someone syncs his
> databases, almost the same signatures are being served...

Honestly you're worried about a non-issue here. The size of the DBs is
fine before and after, and we already serve up 98% of the same info
every time someone downloads a DB; package signatures are not that
different from any other field already there.

-Dan
 
Old 06-19-2010, 02:01 PM
Denis A. Altoé Falqueto
 
Default More thought about signature implementation

On Sat, Jun 19, 2010 at 10:47 AM, Dan McGee <dpmcgee@gmail.com> wrote:
> Honestly you're worried about a non-issue here. The size of the DBs is
> fine before and after, and we already serve up 98% of the same info
> every time someone downloads a DB; package signatures are not that
> different from any other field already there.

Alright. I'm not really worried, just wanted to discuss it now, before
someone comes to nag. To me it is fine and have advantages too.

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

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 

Thread Tools




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

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