On 16/09/12 15:59, Gaetan Bisson wrote:
(it's by Florian P,
and of course I trust him)
Where there goes the point of failure right there!
Remember there is also the files.db which is ~10x the size. I guess we
should sign that too?
Allan
On Sun, Sep 16, 2012 at 7:59 AM, Gaetan Bisson bis...@archlinux.org wrote:
Do we really need remote signing for the DB, given that each of us
already downloads the DB when upgrading, most likely several times a
day? I do not think downloading it a couple more times when pushing
packages will
On 09/12/2012 03:01 PM, Alexander Rødseth wrote:
Can I have access to [multilib] so I can remove chuck? (and possibly
make other useful changes to multilib in the future).
I've the same request. I want to bring to [multilib] lib32-fmodex and
some other dependencies used by games without x86_64
Am 16.09.2012 08:34, schrieb Jan Steffens:
On Sun, Sep 16, 2012 at 7:59 AM, Gaetan Bisson bis...@archlinux.org wrote:
Do we really need remote signing for the DB, given that each of us
already downloads the DB when upgrading, most likely several times a
day? I do not think downloading it a
=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 9 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 11 fully signed off packages
* 25 packages missing signoffs
* 0 packages older than 14 days
(Note:
Am 16.09.2012 08:41, schrieb Bartłomiej Piotrowski:
On 09/12/2012 03:01 PM, Alexander Rødseth wrote:
Can I have access to [multilib] so I can remove chuck? (and possibly
make other useful changes to multilib in the future).
I've the same request. I want to bring to [multilib] lib32-fmodex
Am 16.09.2012 08:34, schrieb Jan Steffens:
I want avoid anything that requires me to upload the DB from my computer.
[...]
That would be over 7MB I would have to download and upload
Would we really need to sign the full 7MB database? Could we not come
up with something more minimal to sign
Tom Gundersen wrote:
Am 16.09.2012 08:34, schrieb Jan Steffens:
I want avoid anything that requires me to upload the DB from my computer.
[...]
That would be over 7MB I would have to download and upload
Why can't the following procedure be used?
1) update the database on the server
2)
On 16/09/12 23:56, Xyne wrote:
Tom Gundersen wrote:
Am 16.09.2012 08:34, schrieb Jan Steffens:
I want avoid anything that requires me to upload the DB from my
computer.
[...]
That would be over 7MB I would have to download and upload
Why can't the following procedure be used?
Allan McRae wrote:
What does check it and sign it mean? Diff it to the old and signed
database?
By check it I mean check that each signature in the database is authentic and
trusted, and that every package in the database is signed. I thought there was
an easy way to verify each signature's
[2012-09-16 16:03:19 +] Xyne:
By check it I mean check that each signature in the database is authentic
and
trusted, and that every package in the database is signed.
Signing the DB serves a completely different purpose to all the
signatures on its packages.
--
Gaetan
Gaetan Bisson wrote:
[2012-09-16 16:03:19 +] Xyne:
By check it I mean check that each signature in the database is authentic
and
trusted, and that every package in the database is signed.
Signing the DB serves a completely different purpose to all the
signatures on its packages.
I see
Xyne wrote:
If they are kept in the database then signing the database file itself may be
unnecessary. Pacman could verify the integrity of the metadata for each package
when it downloads the database.
Adding to that idea, pacman currently verifies database signatures each time it
is run. If the
[2012-09-16 23:33:39 +] Xyne:
I see now that what I proposed would not ensure the integrity of package
metadata such as dependencies.
As the metadata is found within packages (.pkg.tar.xz), package
signatures (.pkg.tar.xz.sig) ensure their integrity and, more
importantly, authenticity.
The
14 matches
Mail list logo
