And another update...
On Fri, Nov 15, 2019 at 05:23:41PM +, Steve McIntyre wrote:
>
>On Fri, Oct 25, 2019 at 05:01:07PM +0100, Steve McIntyre wrote:
>>
>>I'll take a look at that shortly. Working on the core jigdo tool first.
>
>I have new versions of jigdo and jigit just about ready to go. I'
Following up here for information on progress...
On Fri, Oct 25, 2019 at 05:01:07PM +0100, Steve McIntyre wrote:
>
>I'll take a look at that shortly. Working on the core jigdo tool first.
I have new versions of jigdo and jigit just about ready to go. I've
defined a new format v2 for jigdo, which
Daniel Kahn Gillmor (2019-10-22):
> The Packages file is growing, and we would like to keep it smaller.
>
> The MD5sum lines are vestigial at this point. Anything that they do
> can be done better with the data from the SHA256sum lines.
>
> Removal of the MD5sum lines would reduce the size of t
On Thu, Oct 24, 2019 at 01:27:44PM +0200, Thomas Schmitt wrote:
>Hi,
>
>i wrote:
>> How about mirror checking by SHA256 in grab_md5, before computing the
>> MD5 for jigdo ?
>
>Or you could let libjte internally compute both, SHA256 and MD5,
>let it work with SHA256, but store in .jigdo and .templat
Hi,
Daniel Kahn Gillmor wrote:
> Is the final checksum over the whole image also MD5, or do we use
> something stronger?
Currently, the downloader only checks MD5. But it already now has a wide
range of better checksums to choose from.
A typical .jigdo file contains this header part (after gunzi
On Thu 2019-10-24 09:10:50 +0200, Bastian Blank wrote:
> Hi Ansgar
>
> On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
>> We could look into either
>> - writing MD5sum in a separate file only used by debian-cd (if present,
>>otherwise debian-cd should fall back to using Packages), or
>
On Thu 2019-10-24 11:16:10 +0100, Steve McIntyre wrote:
> The vast majority of the usage of MD5 here is for (essentially)
> content-addressable storage. Given the context (with a checksum over
> the whole image too), this is not such a critical failing.
Is the final checksum over the whole image a
On Thu, Oct 24, 2019 at 12:56:53PM +0200, Thomas Schmitt wrote:
>Hi,
>
>i wrote:
>> > [...] MD5s. I'd rather characterize them as relation keys and as
>> > transport checksums.
>
>Steve McIntyre wrote:
>> It's *also* checking for potential corruption in the mirror at build
>> time.
>
>MD5 is well
Hi,
i wrote:
> How about mirror checking by SHA256 in grab_md5, before computing the
> MD5 for jigdo ?
Or you could let libjte internally compute both, SHA256 and MD5,
let it work with SHA256, but store in .jigdo and .template the MD5.
(I just checked the API definition. If you can tolerate the
Hi,
i wrote:
> > [...] MD5s. I'd rather characterize them as relation keys and as
> > transport checksums.
Steve McIntyre wrote:
> It's *also* checking for potential corruption in the mirror at build
> time.
MD5 is well suited for that, as long as this is not considered to be part
of an intrusi
On Thu, Oct 24, 2019 at 09:05:16AM +0200, Thomas Schmitt wrote:
>Hi,
>
>Ansgar wrote:
>> > > From looking, I believe it is debian-cd's tools/grab_md5 that is using
>> > > the MD5sum from Packages (and Sources) to avoid having to compute all
>> > > these checksums itself.
>
>Steve McIntyre wrote:
>>
On Wed, Oct 23, 2019 at 09:29:53PM -0400, Daniel Kahn Gillmor wrote:
>On Wed 2019-10-23 16:39:24 +0100, Steve McIntyre wrote:
>> On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
>>> - writing MD5sum in a separate file only used by debian-cd (if present,
>>> otherwise debian-cd should fall
Hi,
too early in the morning i wrote:
> The security weakness of jigdo-lite download is in the fact that the
> input file .info is not verified at all, [...]
I meant input file ".jigdo", not ".info".
Have a nice day :)
Thomas
Hi,
i wrote falsely:
> The negative e potency nearest to 0 which powl(3) can compute as non-0
> is e exp -1e-18
It would of course have to be "compute as non-1".
Have a nice day :)
Thomas
+
Hi Ansgar
On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
> We could look into either
> - writing MD5sum in a separate file only used by debian-cd (if present,
>otherwise debian-cd should fall back to using Packages), or
We still do that, see /indices/md5sum.gz.
Bastian
--
Hi,
Ansgar wrote:
> > > From looking, I believe it is debian-cd's tools/grab_md5 that is using
> > > the MD5sum from Packages (and Sources) to avoid having to compute all
> > > these checksums itself.
Steve McIntyre wrote:
> > Well, not just that. It grabs them for use in the jigdo file. The
> >
On Wed 2019-10-23 16:39:24 +0100, Steve McIntyre wrote:
> On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
>> - writing MD5sum in a separate file only used by debian-cd (if present,
>> otherwise debian-cd should fall back to using Packages), or
Sounds like this is the only option availabl
On Tue, Oct 22, 2019 at 11:51:56PM +0200, Ansgar wrote:
>Daniel Kahn Gillmor writes:
>> The Packages file is growing, and we would like to keep it smaller.
>>
>> The MD5sum lines are vestigial at this point. Anything that they do
>> can be done better with the data from the SHA256sum lines.
>
>I a
Hi,
since Steve McIntyre seems to be busy, i try to answer the general
questions about jigdo.
The files .jigdo and .template get created by xorriso along with the
creation of the .iso image file.
The MD5s in .jigdo and .template are used for bringing together the
file items in both formats. .tem
Daniel Kahn Gillmor writes:
> The Packages file is growing, and we would like to keep it smaller.
>
> The MD5sum lines are vestigial at this point. Anything that they do
> can be done better with the data from the SHA256sum lines.
I agree it would be nice to remove MD5sum from Packages; there are
Package: ftp.debian.org
Severity: normal
The Packages file is growing, and we would like to keep it smaller.
The MD5sum lines are vestigial at this point. Anything that they do
can be done better with the data from the SHA256sum lines.
Removal of the MD5sum lines would reduce the size of the gz
21 matches
Mail list logo
