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 > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-11-2010, 09:41 AM
Andre Robatino
 
Default RPM: signing uncompressed data instead of signed data?

I came across the following old post, which I'm not responding to in-thread due
to its age.

https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517.html

The question was raised why RPMs sign their compressed data, rather than
uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
changes in compression such as the recent one in xz.) The answer had to do with
the fact that higher-level tools (createrepo and yum) depend on the current
behavior, but that doesn't address whether it's just an early design mistake
that we're locked into now, or if there's actually some overall advantage to
doing things this way (that outweighs the obvious disadvantage of inflexibility
in how the data is compressed). Can anyone shed some light on this?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 01:02 PM
Bruno Wolff III
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, Nov 11, 2010 at 10:41:13 +0000,
Andre Robatino <robatino@fedoraproject.org> wrote:
>
> The question was raised why RPMs sign their compressed data, rather than
> uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
> changes in compression such as the recent one in xz.) The answer had to do with
> the fact that higher-level tools (createrepo and yum) depend on the current
> behavior, but that doesn't address whether it's just an early design mistake
> that we're locked into now, or if there's actually some overall advantage to
> doing things this way (that outweighs the obvious disadvantage of inflexibility
> in how the data is compressed). Can anyone shed some light on this?

Uncompressing hostile data is generally not a good thing to be doing. From
that aspect it makes more sense to sign the compressed payload.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 01:29 PM
Andre Robatino
 
Default RPM: signing uncompressed data instead of signed data?

Bruno Wolff III wrote:

> Uncompressing hostile data is generally not a good thing to be doing.
> From that aspect it makes more sense to sign the compressed payload.

I was thinking that since the signature check usually passes, the data
could be uncompressed into a cache, checked there, then copied into
place (assuming the check passes). If the data is capable of escaping
from that sandbox before being checked, that's a serious security bug in
the compression software that should be fixed in any case.

(Sorry for not responding in-thread. Gmane isn't updating its list of
existing threads.)

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 01:41 PM
James Antill
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, 2010-11-11 at 10:41 +0000, Andre Robatino wrote:
> I came across the following old post, which I'm not responding to in-thread due
> to its age.
>
> https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517.html
>
> The question was raised why RPMs sign their compressed data, rather than
> uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to
> changes in compression such as the recent one in xz.)

That's not true, there are four checks for delta rpms:

1. yum-presto runs checksums on the installed rpm, and the downloaded
deltarpm. If these pass it then creates a new .rpm from those two
sources.

2. Yum then checks that any rpm it has on disk matches the checksum it
has from the repodata.

3. Yum then asks rpm to check the gpg signature of the new rpm.

4. Yum then looks at the SHA1HEADER for the rpm (which, again, is over
the compressed contents).

...now it's possible that #3 will change within the next year or so, but
it is much more likely to end up simpler than more complicated (Eg.
detached signature of the entire file).
IMO, as has been said before, if you have a delta method that doesn't
produce the exact same bits at the end ... you've probably failed. It
might seem like a good idea, but even if you go to the extreme lengths
needed to make it just for yum ... things like reposync won't be able to
use it, Eg.

http://james.fedorapeople.org/python/delta-rpm-dir.py

--
James Antill - james@fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.29
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 01:49 PM
Bruno Wolff III
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, Nov 11, 2010 at 09:29:54 -0500,
Andre Robatino <robatino@fedoraproject.org> wrote:
> Bruno Wolff III wrote:
>
> > Uncompressing hostile data is generally not a good thing to be doing.
> > From that aspect it makes more sense to sign the compressed payload.
>
> I was thinking that since the signature check usually passes, the data
> could be uncompressed into a cache, checked there, then copied into
> place (assuming the check passes). If the data is capable of escaping
> from that sandbox before being checked, that's a serious security bug in
> the compression software that should be fixed in any case.

The issue is the uncompression itself rather than the resulting uncompressed
data being used. It is easy to do a DOS by compressing a very large file
of constant data and having the victum fill up their disk. Also compression /
decompression seems to be an area where proper paranoia isn't practiced and
malformed data can cause problems. There have been several cases of libraries
handling compressed image formats allowing arbitrary execution of code when
operating on trojan images. I suspect that historically the people writing
this kind of code were more interested in speed than security.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 02:17 PM
Andre Robatino
 
Default RPM: signing uncompressed data instead of signed data?

James Antill wrote:

> IMO, as has been said before, if you have a delta method that doesn't
> produce the exact same bits at the end ... you've probably failed. It
> might seem like a good idea, but even if you go to the extreme lengths
> needed to make it just for yum ... things like reposync won't be able
> to use it, Eg.
>
> http://james.fedorapeople.org/python/delta-rpm-dir.py

I realize there's a lot of stuff sitting on top of RPM that depends on
how it works currently, but in terms of correctness, it still seems to
me to make more sense to sign the uncompressed data, since that's what
actually gets used, and it would avoid issues like
https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
with periodically as long as compression continues to improve. So let me
rephrase the question: in an alternate universe where RPM was originally
designed to sign the uncompressed data, and the higher-level tools were
subsequently designed to work with that, is there any fundamental reason
why things would be worse (or better) than they are now?

(Again, sorry for not replying in-thread, but Gmane isn't updating.)


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 02:40 PM
Michael Schroeder
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, Nov 11, 2010 at 10:17:57AM -0500, Andre Robatino wrote:
> I realize there's a lot of stuff sitting on top of RPM that depends on
> how it works currently, but in terms of correctness, it still seems to
> me to make more sense to sign the uncompressed data, since that's what
> actually gets used, and it would avoid issues like
> https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
> with periodically as long as compression continues to improve. So let me
> rephrase the question: in an alternate universe where RPM was originally
> designed to sign the uncompressed data, and the higher-level tools were
> subsequently designed to work with that, is there any fundamental reason
> why things would be worse (or better) than they are now?

Securitywise ist would be a bit worse, because the decompression
libraries may contain exploitable bugs, so checking the
signature of a rpm might be already a dangerous operation.

(But most repositories nowadays already contain checksums over
the complete rpm, and most people trust repositories, not
individual rpms.)

Cheers,
Michael.

--
Michael Schroeder mls@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 02:50 PM
John Reiser
 
Default RPM: signing uncompressed data instead of signed data?

On 11/11/2010 07:17 AM, Andre Robatino wrote:
> in an alternate universe where RPM was originally
> designed to sign the uncompressed data, and the higher-level tools were
> subsequently designed to work with that, is there any fundamental reason
> why things would be worse (or better) than they are now?

The bytes that are signed would be "farther away" from the contents
of the .rpm file. The compression would occur in between the signing
and packing the file, so the signing would be less "end-to-end" with
respect to packing the contents into the file. This changes the
data integrity implications of signature that does not match.
Some uses want more protection against "mere transmission errors" of the file,
other uses want more independence of the various steps in a larger process
(ability to change compression without changing signature, for example.)

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-11-2010, 03:36 PM
James Antill
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, 2010-11-11 at 10:17 -0500, Andre Robatino wrote:
> James Antill wrote:
>
> > IMO, as has been said before, if you have a delta method that doesn't
> > produce the exact same bits at the end ... you've probably failed. It
> > might seem like a good idea, but even if you go to the extreme lengths
> > needed to make it just for yum ... things like reposync won't be able
> > to use it, Eg.
> >
> > http://james.fedorapeople.org/python/delta-rpm-dir.py
>
> I realize there's a lot of stuff sitting on top of RPM that depends on
> how it works currently

Maybe I wasn't clear ... the above code doesn't "depend on rpm" it
depends on the bits being identical, as it's used to speed up mirroring
Fedora (so the bits have to be identical for the mirror users).

> , but in terms of correctness, it still seems to
> me to make more sense to sign the uncompressed data, since that's what
> actually gets used

"used" is a loaded word here, as others have said from the point of
view of different parts of yum/rpm it's the downloaded bits that are
"used" and the uncompressed bits that are output.

> , and it would avoid issues like
> https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
> with periodically as long as compression continues to improve. So let me
> rephrase the question: in an alternate universe where RPM was originally
> designed to sign the uncompressed data, and the higher-level tools were
> subsequently designed to work with that, is there any fundamental reason
> why things would be worse (or better) than they are now?

So assuming we could magically change everything, what would we need to
do stop any differences in compression from causing problems? In theory
we could publish everything as uncompressed ... and then use http
content-encoding to add xz/etc. compression back.
But that'd break everything that's non-http ... and any http clients
that don't do content-encoding (and AFAIK no client/server currently
supports xz in content-encoding).

The other option is for someone to add compat. code into xz, so we can
say things like "compress how you would have with version x.y.z".

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Thu Nov 11 18:30:01 2010
Return-path: <centos-bounces@centos.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 11 Nov 2010 17:38:36 +0200
Received: from mail.centos.org ([72.26.200.202]:57577)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <centos-bounces@centos.org>)
id 1PGZER-0000Bc-PR
for tom@linux-archive.org; Thu, 11 Nov 2010 17:38:35 +0200
Received: from mail.centos.org (voxeldev.centos.org [127.0.0.1])
by mail.centos.org (Postfix) with ESMTP id D35196F83E;
Thu, 11 Nov 2010 11:36:01 -0500 (EST)
X-Original-To: centos@centos.org
Delivered-To: centos@centos.org
Received: from mail.filmakademie.de (mail.filmakademie.de [193.196.129.3])
by mail.centos.org (Postfix) with ESMTP id 14F6B67B8A
for <centos@centos.org>; Thu, 11 Nov 2010 11:35:59 -0500 (EST)
Received: from mac10337.local ([172.17.22.29]) (authenticated bits=0)
by mail.filmakademie.de (8.13.8/8.13.8) with ESMTP id oABGZtGJ020833
(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)
for <centos@centos.org>; Thu, 11 Nov 2010 17:35:56 +0100
Message-ID: <4CDC1B6B.6020808@filmakademie.de>
Date: Thu, 11 Nov 2010 17:35:55 +0100
From: =?ISO-8859-1?Q?G=F6tz_Reinicke_-_IT-Koordinator?=
<goetz.reinicke@filmakademie.de>
Organization: Filmakademie =?ISO-8859-1?Q?Baden-W=FCrttemberg_GmbH?=
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de;
rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: CentOS mailing list <centos@centos.org>
References: <AANLkTi=0Pc5O9Szc+kH5BU=9LP0foaoB2zOhR_Yw6pbP@mai l.gmail.com> <AANLkTi=77r65kEuLJ9wubO_EN9q0-R+CebKAYWo4+FXd@mail.gmail.com> <20101110204323.GA19286@jadzia.bu.edu> <4CDB1C34.302@htt-consult.com> <Pine.LNX.4.64.1011101631200.29153@flxi10.fnal.gov > <4CDB229B.5060706@htt-consult.com>
<4CDB9610.9090508@filmakademie.de> <4CDC037D.4070708@htt-consult.com> <4CDC158A.6070408@filmakademie.de>
<alpine.LRH.2.00.1011111116480.3320@localhost.loca ldomain>
In-Reply-To: <alpine.LRH.2.00.1011111116480.3320@localhost.loca ldomain>
X-Enigmail-Version: 1.1.1
X-Filmakademie-MailScanner-Information: Please contact the ISP for more
information
X-Filmakademie-MailScanner-ID: oABGZtGJ020833
X-Filmakademie-MailScanner: Found to be clean
X-Filmakademie-MailScanner-SpamCheck: not spam,
SpamAssassin (nicht zwischen gespeichert, Wertung=-16.8,
benoetigt 3.6, autolearn=disabled, ALL_TRUSTED -1.80,
BAYES_00 -15.00)
X-Filmakademie-MailScanner-From: goetz.reinicke@filmakademie.de
Subject: Re: [CentOS] RHEL 6 Officially Released
X-BeenThere: centos@centos.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: CentOS mailing list <centos@centos.org>
List-Id: CentOS mailing list <centos.centos.org>
List-Unsubscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=unsubscribe>
List-Archive: <http://lists.centos.org/pipermail/centos>
List-Post: <mailto:centos@centos.org>
List-Help: <mailto:centos-request@centos.org?subject=help>
List-Subscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1875005867=="
Sender: centos-bounces@centos.org
Errors-To: centos-bounces@centos.org

This is a cryptographically signed message in MIME format.

--===============1875005867==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms000501040206080607050701"

This is a cryptographically signed message in MIME format.

--------------ms000501040206080607050701
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 11.11.10 17:17, schrieb Scot P. Floess:
>=20
> Is it an x86_64 install? I had a problem with Xen last year under 5.x
> whereby I had to increase the VM's memory footprint to 512 MB
>=20
> On Thu, 11 Nov 2010, G=F6tz Reinicke - IT-Koordinator wrote:
>=20
>> Am 11.11.10 15:53, schrieb Robert Moskowitz:
>>>
>>>
>>> On 11/11/2010 01:06 AM, G=F6tz Reinicke - IT-Koordinator wrote:
>>>> Am 10.11.10 23:54, schrieb Robert Moskowitz:
>>>>
>>>>> On 11/10/2010 04:33 PM, Connie Sieh wrote:
>>>>>
>>>>>> On Wed, 10 Nov 2010, Robert Moskowitz wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 11/10/2010 02:43 PM, Matthew Miller wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Nov 10, 2010 at 02:40:52PM -0600, Matt wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> What does 6 bring with it? Anything new in virtualization and
>>>>>>>>> cloud computing?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> http://www.redhat.com/rhel/server/details/
>>>>>>>>
>>>>>>>>
>>>>>>> I don't see here what version of BIND is included. Anyone know?
>>>>>>>
>>>>>>>
>>>>>> bind-9.7.0-5.P2
>>>>>>
>>>>>> To determine other versions the src.rpm's are located at
>>>>>>
>>>>>> ftp://ftp.redhat.com/redhat/linux/enterprise/6/en/source/SRPMS/
>>>>>>
>>>>> And what are the minimum system requirements? Will we still be
>>>>> able to
>>>>> install this on a 256Mb system for example?
>>>>>
>>>> http://www.redhat.com/rhel/compare/
>>>
>>> Great! Now I know what to look for I can put the right search string=

>>> into google to get this page!
>>>
>>> Well that has the information I was looking for except....
>>>
>>> It says there that RHEL 5's minimum memory is 512Mb. Last week I
>>> installed Centos 5.5 on a test system with 256Mb with a 1Gb of cache:=

>>>
>>> # free
>>> total used free shared buffers =20
>>> cached
>>> Mem: 254124 235864 18260 0 5952 =20
>>> 97668
>>> -/+ buffers/cache: 132244 121880
>>> Swap: 1052248 151876 900372
>>>
>>> So I hope that Centos 6 will continue to be installable on a 256Mb
>>> system. It does not pay to replace the memory on these test systems.=
I
>>> can pick up 1Gb used SFF systems for about the same price as 512Mb
>>> memory for these old boxes.
>>>
>>
>> I just tried to install RH EL 6 on a virtual mashine with 256 MB. Just=

>> after the installer boots it says 'You do not have enough RAM to insta=
ll
>> ....'
>>
>> /G=F6tz
>>

Yes it is an x86_64 I tried.

/g=F6tz


--=20
G=F6tz Reinicke
IT-Koordinator

Tel. +49 7141 969 420
Fax +49 7141 969 55 420
E-Mail goetz.reinicke@filmakademie.de

Filmakademie Baden-W=FCrttemberg GmbH
Akademiehof 10
71638 Ludwigsburg
www.filmakademie.de

Eintragung Amtsgericht Stuttgart HRB 205016
Vorsitzende des Aufsichtsrats:
Prof. Dr. Claudia H=FCbner

Gesch=E4ftsf=FChrer:
Prof. Thomas Schadt


--------------ms000501040206080607050701
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIVNTCC
BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBg NVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbG VTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMj AeFw0wNjEyMTkxMDI5MDBa
Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQ QKEwpERk4tVmVyZWluMRAw
DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIF BDQSBHbG9iYWwgLSBHMDEw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8Nnhf kNrvWNVMOWUDU9YuluTO2U
1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QR dDtoAB6
fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq 3u3ibo7wGvdA/BCaL2a869
080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81h n1vM7PbD8URwoqD
oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzU lU28kTNJpxdcVs6qcLmPkh
nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBG kwZzBloGOgYYZfaHR0cDov
L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3 dubG9hZEFSTC5jcmw/LWNy
bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQ YDVR0OBBYEFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei 0XbAqzK50zMA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX
3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR
M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6Xcgja K95qGFKUD2P3MyWA0Ja6ba
hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ
hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOy H
xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFXjCCBEagAwIBAgIEEBtOAjAN
BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UECh MKREZOLVZlcmVpbjEQMA4G
A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0 EgR2xvYmFsIC0gRzAxMB4X
DTEwMDUyNTEzMjgxOVoXDTE5MDYzMDAwMDAwMFowgcoxCzAJBg NVBAYTAkRFMRswGQYDVQQI
ExJCYWRlbi1XdWVydHRlbWJlcmcxFDASBgNVBAcTC0x1ZHdpZ3 NidXJnMS0wKwYDVQQKEyRG
aWxtYWthZGVtaWUgQmFkZW4tV3VlcnR0ZW1iZXJnIEdtYkgxFT ATBgNVBAsTDElUIE9mZmlj
ZU5ldDEaMBgGA1UEAxMRRkEgTHVkd2lnc2J1cmcgQ0ExJjAkBg kqhkiG9w0BCQEWF2NhLWZh
bHVAZmlsbWFrYWRlbWllLmRlMIIBIjANBgkqhkiG9w0BAQEFAA OCAQ8AMIIBCgKCAQEA0mMf
lkuyiVXWqKo8TpRjIJWhIkmCr/singYPLtM5wXTfvpGhCOnkVOeEb0Qzy/C3zNlIrLObsJ78
1AwKNRyXOTW2T7fA3JrQPEFsahjXmVsWLDBCyA0S2uQa/0xStMET7m+MxohJVJ5503M6T+Xg
kuwW3r7xq7gB7CjHSK7n0VdrrDWamqES1cBr7GJutCZNfic/PXsW3QO7hOT3Y/XX0RnX5OJr
uMFF5V7qyb/Q+Ma9U5NGaqy4FakTLyTK4naP+N8Gvlnqn41/sUdNXwx4YMvCTUEH4ujAB6Wf
vP+OPnnOrjzPElcfs6JXQ2P9Wxhvrx0EaAdH7e5w1oZb00sSvQ IDAQABo4IBuTCCAbUwEgYD
VR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFM3uRxJyPeKNeVu s3iNL
fQZwWJi8MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMCIGA1UdEQQbMBmBF2Nh
LWZhbHVAZmlsbWFrYWRlbWllLmRlMIGIBgNVHR8EgYAwfjA9oD ugOYY3aHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3 JsLmNybDA9oDugOYY3aHR0
cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdW IvY3JsL2NhY3JsLmNybDCB
ogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly 9jZHAxLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME cGCCsGAQUFBzAChjtodHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi 9jYWNlcnQvY2FjZXJ0LmNy
dDANBgkqhkiG9w0BAQUFAAOCAQEAupdwxPU9OGGH4qGEKBMO2d UjTZtSIYJyW8uN1cMgv2cD
gkZpFXEycEgpp+gm7gzvup3TC0010XnZ3jVuNycEuClJLB1elY DrCRTHH46lTglPygxzeSO0
Ybv94qx4Q0pCK2IplBYPvmcHGrWmSUIXEDzbIFBf38lv9/YO5AgFijdU+V5DbEBzbcBHZ4OL
G9Mjpi0pW6wPEJw5jel5O/NmJOQ1G+pOPwHfbPowaiTnDTs3JRBdy5xzGLzt6dLvp7agEHpX
ENZoIVdtuEE6nKdouJGcuPqyySZBQ6xsSV0ppH+ezLciEWshS5 KkBFSf8YQ1z9NVIi09y1Hx
Gt3szSO5STCCBdMwggS7oAMCAQICBBA+n+0wDQYJKoZIhvcNAQ EFBQAwgcoxCzAJBgNVBAYT
AkRFMRswGQYDVQQIExJCYWRlbi1XdWVydHRlbWJlcmcxFDASBg NVBAcTC0x1ZHdpZ3NidXJn
MS0wKwYDVQQKEyRGaWxtYWthZGVtaWUgQmFkZW4tV3VlcnR0ZW 1iZXJnIEdtYkgxFTATBgNV
BAsTDElUIE9mZmljZU5ldDEaMBgGA1UEAxMRRkEgTHVkd2lnc2 J1cmcgQ0ExJjAkBgkqhkiG
9w0BCQEWF2NhLWZhbHVAZmlsbWFrYWRlbWllLmRlMB4XDTEwMD YyMTA4MjcwOVoXDTEzMDYy
MDA4MjcwOVowVTELMAkGA1UEBhMCREUxLTArBgNVBAoTJEZpbG 1ha2FkZW1pZSBCYWRlbi1X
dWVydHRlbWJlcmcgR21iSDEXMBUGA1UEAxMOR29ldHogUmVpbm lja2UwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCvJgdLf/1lSZt6/cdJ6fQPJ+pBLsLm+0Zt/5xxELD30fVg
YS3ocYfwesyoBR0wiryR0dlNGISElfhssanYCluoF4RIi1LyUS GZbf6Dz3bpoqGRoLu5FJrX
thbD23AopV/s8RNm8P2qTBHuPtvBrIR2r52uV9/pZkdESFkXmC3AEStYaJJGG13JbGaYIg4I
exzH0Pxw9bvPxzv/iRDznV66RpY+hRyky4ouxaKp43rZbfeHQEbTMApWI8ck1OqhYk drv+/V
3M5nI1Zck9aWukAkE9aHeU9NUhv5ThHCIt6FavBHpx+clxR8v+ qXz4mdSIwGhhM35kSqH05/
PluzXkutAgMBAAGjggIzMIICLzAJBgNVHRMEAjAAMAsGA1UdDw QEAwIF4DApBgNVHSUEIjAg
BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR 0OBBYEFKoQ/yRAmIMHBjxL
X0t/ZyUP8YdfMB8GA1UdIwQYMBaAFM3uRxJyPeKNeVus3iNLfQZwWJ i8MCkGA1UdEQQiMCCB
HmdvZXR6LnJlaW5pY2tlQGZpbG1ha2FkZW1pZS5kZTCBsQYDVR 0fBIGpMIGmMFGgT6BNhkto
dHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZpbG1ha2FkZW1pZS1iYW Rlbi13dWVydHRlbWJlcmct
Y2EvcHViL2NybC9jYWNybC5jcmwwUaBPoE2GS2h0dHA6Ly9jZH AyLnBjYS5kZm4uZGUvZmls
bWFrYWRlbWllLWJhZGVuLXd1ZXJ0dGVtYmVyZy1jYS9wdWIvY3 JsL2NhY3JsLmNybDCBygYI
KwYBBQUHAQEEgb0wgbowWwYIKwYBBQUHMAKGT2h0dHA6Ly9jZH AxLnBjYS5kZm4uZGUvZmls
bWFrYWRlbWllLWJhZGVuLXd1ZXJ0dGVtYmVyZy1jYS9wdWIvY2 FjZXJ0L2NhY2VydC5jcnQw
WwYIKwYBBQUHMAKGT2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZm lsbWFrYWRlbWllLWJhZGVu
LXd1ZXJ0dGVtYmVyZy1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcn QwDQYJKoZIhvcNAQEFBQAD
ggEBAK0DGenAT6oI+vu+21AOtGbKf6erWSJOG9p9ltL8/jGvl28YlhSESl1CnElIRDIJKqNT
HeO9Wp17Yutay+xXMm8Qdesf6jQcJLiVLRnqbwdDj8Bp1JGU50 bo4tRM4BPRGN4TQ1zjouvk
lk20BXrdA9iSEBQ35DtGjn4AeKkdZxGMFiT9FulUvWVOTVoTZw UZUuo6iggoAwM4l5UgN5Ug
beRvJZFNKyaIneFIME7k1RyLoAYZZEoN1VuvovyGcw4gApRFQI mRgwnhCNN9E6fbjJbZ9Y6j
YYWLqSHzKcLR80vyj1rYXSbUf8ML6tyg34fX6zh0uYVOwWmxj7 Fj7vmRoJowggXTMIIEu6AD
AgECAgQQPp/tMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJERTEbMBkGA 1UECBMSQmFk
ZW4tV3VlcnR0ZW1iZXJnMRQwEgYDVQQHEwtMdWR3aWdzYnVyZz EtMCsGA1UEChMkRmlsbWFr
YWRlbWllIEJhZGVuLVd1ZXJ0dGVtYmVyZyBHbWJIMRUwEwYDVQ QLEwxJVCBPZmZpY2VOZXQx
GjAYBgNVBAMTEUZBIEx1ZHdpZ3NidXJnIENBMSYwJAYJKoZIhv cNAQkBFhdjYS1mYWx1QGZp
bG1ha2FkZW1pZS5kZTAeFw0xMDA2MjEwODI3MDlaFw0xMzA2Mj AwODI3MDlaMFUxCzAJBgNV
BAYTAkRFMS0wKwYDVQQKEyRGaWxtYWthZGVtaWUgQmFkZW4tV3 VlcnR0ZW1iZXJnIEdtYkgx
FzAVBgNVBAMTDkdvZXR6IFJlaW5pY2tlMIIBIjANBgkqhkiG9w 0BAQEFAAOCAQ8AMIIBCgKC
AQEAryYHS3/9ZUmbev3HSen0DyfqQS7C5vtGbf+ccRCw99H1YGEt6HGH8HrMq AUdMIq8kdHZ
TRiEhJX4bLGp2ApbqBeESItS8lEhmW3+g8926aKhkaC7uRSa17 YWw9twKKVf7PETZvD9qkwR
7j7bwayEdq+drlff6WZHREhZF5gtwBErWGiSRhtdyWxmmCIOCH scx9D8cPW7z8c7/4kQ851e
ukaWPoUcpMuKLsWiqeN62W33h0BG0zAKViPHJNTqoWJHa7/v1dzOZyNWXJPWlrpAJBPWh3lP
TVIb+U4RwiLehWrwR6cfnJcUfL/ql8+JnUiMBoYTN+ZEqh9Ofz5bs15LrQIDAQABo4ICMzCC
Ai8wCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYDVR0lBCIwIA YIKwYBBQUHAwIGCCsGAQUF
BwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBSqEP8kQJiDBwY8S1 9Lf2clD/GHXzAfBgNVHSME
GDAWgBTN7kcScj3ijXlbrN4jS30GcFiYvDApBgNVHREEIjAggR 5nb2V0ei5yZWluaWNrZUBm
aWxtYWthZGVtaWUuZGUwgbEGA1UdHwSBqTCBpjBRoE+gTYZLaH R0cDovL2NkcDEucGNhLmRm
bi5kZS9maWxtYWthZGVtaWUtYmFkZW4td3VlcnR0ZW1iZXJnLW NhL3B1Yi9jcmwvY2Fjcmwu
Y3JsMFGgT6BNhktodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ZpbG 1ha2FkZW1pZS1iYWRlbi13
dWVydHRlbWJlcmctY2EvcHViL2NybC9jYWNybC5jcmwwgcoGCC sGAQUFBwEBBIG9MIG6MFsG
CCsGAQUFBzAChk9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZpbG 1ha2FkZW1pZS1iYWRlbi13
dWVydHRlbWJlcmctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MF sGCCsGAQUFBzAChk9odHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2ZpbG1ha2FkZW1pZS1iYWRlbi 13dWVydHRlbWJlcmctY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4 IBAQCtAxnpwE+qCPr7vttQ
DrRmyn+nq1kiThvafZbS/P4xr5dvGJYUhEpdQpxJSEQyCSqjUx3jvVqde2LrWsvsVzJvEHX r
H+o0HCS4lS0Z6m8HQ4/AadSRlOdG6OLUTOAT0RjeE0Nc46Lr5JZNtAV63QPYkhAUN+Q7R o5+
AHipHWcRjBYk/RbpVL1lTk1aE2cFGVLqOooIKAMDOJeVIDeVIG3kbyWRTSsmiJ3 hSDBO5NUc
i6AGGWRKDdVbr6L8hnMOIAKURUCJkYMJ4QjTfROn24yW2fWOo2 GFi6kh8ynC0fNL8o9a2F0m
1H/DC+rcoN+H1+s4dLmFTsFpsY+xY+75kaCaMYIEjTCCBIkCAQEwg dMwgcoxCzAJBgNVBAYT
AkRFMRswGQYDVQQIExJCYWRlbi1XdWVydHRlbWJlcmcxFDASBg NVBAcTC0x1ZHdpZ3NidXJn
MS0wKwYDVQQKEyRGaWxtYWthZGVtaWUgQmFkZW4tV3VlcnR0ZW 1iZXJnIEdtYkgxFTATBgNV
BAsTDElUIE9mZmljZU5ldDEaMBgGA1UEAxMRRkEgTHVkd2lnc2 J1cmcgQ0ExJjAkBgkqhkiG
9w0BCQEWF2NhLWZhbHVAZmlsbWFrYWRlbWllLmRlAgQQPp/tMAkGBSsOAwIaBQCgggKOMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ 8XDTEwMTExMTE2MzU1NVow
IwYJKoZIhvcNAQkEMRYEFMy2FT151+LH4AwlJy0o1Sf0ThijMF 8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAg IAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB5AYJKwYBBAGCNx AEMYHWMIHTMIHKMQswCQYD
VQQGEwJERTEbMBkGA1UECBMSQmFkZW4tV3VlcnR0ZW1iZXJnMR QwEgYDVQQHEwtMdWR3aWdz
YnVyZzEtMCsGA1UEChMkRmlsbWFrYWRlbWllIEJhZGVuLVd1ZX J0dGVtYmVyZyBHbWJIMRUw
EwYDVQQLEwxJVCBPZmZpY2VOZXQxGjAYBgNVBAMTEUZBIEx1ZH dpZ3NidXJnIENBMSYwJAYJ
KoZIhvcNAQkBFhdjYS1mYWx1QGZpbG1ha2FkZW1pZS5kZQIEED 6f7TCB5gYLKoZIhvcNAQkQ
AgsxgdaggdMwgcoxCzAJBgNVBAYTAkRFMRswGQYDVQQIExJCYW Rlbi1XdWVydHRlbWJlcmcx
FDASBgNVBAcTC0x1ZHdpZ3NidXJnMS0wKwYDVQQKEyRGaWxtYW thZGVtaWUgQmFkZW4tV3Vl
cnR0ZW1iZXJnIEdtYkgxFTATBgNVBAsTDElUIE9mZmljZU5ldD EaMBgGA1UEAxMRRkEgTHVk
d2lnc2J1cmcgQ0ExJjAkBgkqhkiG9w0BCQEWF2NhLWZhbHVAZm lsbWFrYWRlbWllLmRlAgQQ
Pp/tMA0GCSqGSIb3DQEBAQUABIIBAEqEN8TtVrSMraWwR5lAIfcbU PCj81AYQwZDUg7iJrlW
dM3N7eWfx7ZZ4+WJKVgmkFxcT2yHGdVQRelxtJPyDJqy0nM1cn 2Inc2z0YywhF0E7cVL+COm
Z1enoCQnmePF92qMSBY/1f39KTxdkcDEBEkXpFYIE77JPztUOWoU7nhp7jTxbfLf4OM6Py eG
dqLQEYgqWco9wkHp4XWyu+huNWgCbGefelgVsJYzaqZ0HhaXqr Nkl8djq0Mrjwl58tGv2Rhd
BGx+joett4ALzRpEeKIYl00Nsi4ZrJNfHIu8jKn97Y46sdAE+G Aw0wji4GCE+8S2DjguJTvr
VQXkAhmiJz4AAAAAAAA=
--------------ms000501040206080607050701--

--===============1875005867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

--===============1875005867==--
 
Old 11-14-2010, 12:37 PM
Michel Alexandre Salim
 
Default RPM: signing uncompressed data instead of signed data?

On Thu, 11 Nov 2010 10:17:57 -0500, Andre Robatino wrote:

> James Antill wrote:
>
>> IMO, as has been said before, if you have a delta method that doesn't
>> produce the exact same bits at the end ... you've probably failed. It
>> might seem like a good idea, but even if you go to the extreme lengths
>> needed to make it just for yum ... things like reposync won't be able
>> to use it, Eg.
>>
>> http://james.fedorapeople.org/python/delta-rpm-dir.py
>
> I realize there's a lot of stuff sitting on top of RPM that depends on
> how it works currently, but in terms of correctness, it still seems to
> me to make more sense to sign the uncompressed data, since that's what
> actually gets used, and it would avoid issues like
> https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt
> with periodically as long as compression continues to improve.

This is what 0install uses:
http://0install.net/faq.html



--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: 78884778
Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:42 AM.

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