On Mon, 2009-03-02 at 14:26 +0100, Michael Schroeder wrote:
On Mon, Mar 02, 2009 at 02:29:08PM +0200, Jonathan Dieter wrote:
Do you have a patch to support rpms with SHA-256 payloads? Just asking, because that's where we're heading with F11.
No patch yet, but that shouldn't be hard to support.
Yeah, just ran into some difficulty putting this together. My original plan was to modify deltarpm to be able to read sha256 checksums while sticking with md5 checksums in the deltarpm (to maintain compatibility in rpm-only deltarpms).
The problem is that the sequence is generated from the sha256 checksums, and there's no elegant way (at least as far as I can see) to get md5 checksums for the files in the rpm without completely regenerating them.
The alternative is to use sha256 for all of the checksums in a deltarpm targeting a sha256 rpm, but, like I mentioned earlier, that could cause some issues in the rpm-only deltarpms (the rpm-only format has no tags to specify checksum type, so we'd need to be update the format, and I'm not going to do that without your input).
Is there something I'm missing here? Or will we need to update the rpm-only format?
Jonathan
P.S. CC'ing fedora-devel-list as (at least according the Presto feature page), we're supposed to be generating deltarpms for F11-alpha -> F11-beta after beta freeze, and that can't happen until we get this working.
P.P.S. I just became aware of this last week as I was attempting to create deltarpms for the Presto test Rawhide repository; sorry for the lack of notice, Seth and Luke
On Mon, 9 Mar 2009, Jonathan Dieter wrote:
Yeah, just ran into some difficulty putting this together. My original plan was to modify deltarpm to be able to read sha256 checksums while sticking with md5 checksums in the deltarpm (to maintain compatibility in rpm-only deltarpms).
The problem is that the sequence is generated from the sha256 checksums, and there's no elegant way (at least as far as I can see) to get md5 checksums for the files in the rpm without completely regenerating them.
The alternative is to use sha256 for all of the checksums in a deltarpm targeting a sha256 rpm, but, like I mentioned earlier, that could cause some issues in the rpm-only deltarpms (the rpm-only format has no tags to specify checksum type, so we'd need to be update the format, and I'm not going to do that without your input).
Is there something I'm missing here? Or will we need to update the rpm-only format?
Sounds like the format will need to be updated one way or the other if all of the above is true.
P.S. CC'ing fedora-devel-list as (at least according the Presto feature page), we're supposed to be generating deltarpms for F11-alpha -> F11-beta after beta freeze, and that can't happen until we get this working.
I generated and tested deltarpms but the last time I tested it was before rpm w/sha256 checksums had landed in rawhide.
P.P.S. I just became aware of this last week as I was attempting to create deltarpms for the Presto test Rawhide repository; sorry for the lack of notice, Seth and Luke
Thanks for the heads up - what would you like to do here?
-sv
On Mon, 2009-03-09 at 15:25 -0400, Seth Vidal wrote:
On Mon, 9 Mar 2009, Jonathan Dieter wrote:
<snip>
Is there something I'm missing here? Or will we need to update the rpm-only format?
Sounds like the format will need to be updated one way or the other if all of the above is true.
The good news is that the deltarpms we generate aren't rpm-only, and regular deltarpms start with a copy of the rpm's header (which *does* have the hash format).
We just have to decide whether the checksums deltarpm generates for rpms with sha256 checksums will be sha256 or md5. (And I think we should probably go with sha256, to be consistent.)
<snip>
P.P.S. I just became aware of this last week as I was attempting to create deltarpms for the Presto test Rawhide repository; sorry for the lack of notice, Seth and Luke
Thanks for the heads up - what would you like to do here?
I'm going to wait for Michael's response as he's upstream. I will try modifying deltarpm to only generate sha256 checksums when the rpm contains them, but it looks like it's going to be invasive, and Michael knows the code much better than I do.
Jonathan
Jonathan Dieter wrote:
We just have to decide whether the checksums deltarpm generates for rpms with sha256 checksums will be sha256 or md5. (And I think we should probably go with sha256, to be consistent.)
+1, we're going to SHA256 everywhere for security reasons, so DeltaRPMs should comply as well.
Kevin Kofler
On Mon, Mar 09, 2009 at 08:46:16PM +0200, Jonathan Dieter wrote:
Yeah, just ran into some difficulty putting this together. My original plan was to modify deltarpm to be able to read sha256 checksums while sticking with md5 checksums in the deltarpm (to maintain compatibility in rpm-only deltarpms).
The problem is that the sequence is generated from the sha256 checksums, and there's no elegant way (at least as far as I can see) to get md5 checksums for the files in the rpm without completely regenerating them.
My plan was to just modify the expandseq() function so that it uses sha256 if the checksums stored in the rpm header look like sha256.
I don't think we have any problems with rpm-only deltarpms, as they don't use file checksums at all.
I think we should stay with the overall md5 sum in the sequence to ensure compatibility. This is not a security issue, it's just used to check if the deltarpm can be applied or not.
Cheers, Michael.
On Tue, Mar 10, 2009 at 10:33:44AM +0100, Michael Schroeder wrote:
My plan was to just modify the expandseq() function so that it uses sha256 if the checksums stored in the rpm header look like sha256.
I just did some experiments and it seems that we just need two changes:
- change parsemd5 so that it doesn't complain about too many characters
- change the checkfilemd5/checkprelinked functions so that they use the alroeithm specified in the header's FILEDIGESTALGO tag.
We would compare only the first 16 bytes of the sha256 sums, but that should be no problem as it's not a security relevant check.
Cheers, Michael.