Re: packages without .md5sums file?

On Mon, 30 Jul 2001, Manoj Srivastava wrote: > Not quite. This only requires processing _installed_ > packages. And yes, there is a rtadeoff; Disk space for the archives, > transfers, and CDs' vs processing when a system's integrity is under > suspicion. The latter ought to be a rarer ev

Re: packages without .md5sums file?

>>"Brian" == Brian May <[EMAIL PROTECTED]> writes: Adam> Boot from said trusted CD, run said trusted dpkg, to Adam> calculate the md5sums of the files. Brian> Which requires scanning each and every *.deb file, in order to Brian> calculate the expected check

Re: packages without .md5sums file?

>>>>> "Adam" == Adam Heath <[EMAIL PROTECTED]> writes: Adam> On Sat, 28 Jul 2001, Marcus Brinkmann wrote: >> In contrast, if the md5sums are stored in the package on CD, >> verification is easy: You just need to boot from the (trusted)

Re: packages without .md5sums file?

On Sat, 28 Jul 2001, Marcus Brinkmann wrote: > In contrast, if the md5sums are stored in the package on CD, verification > is easy: You just need to boot from the (trusted) CD, and kick off the > comparison with the CD content. It is easier to trust a list of checksums > mirrored wo

Re: packages without .md5sums file?

e is a Packages file on the CD with md5sum of the package in it, you do not need an additional list of explicit md5sums of each and every file in the package. No additional security is gained from that. Additionally, conffiles are not taken into consideration by these schemes to store ch

Re: packages without .md5sums file?

archive). I think that the checksums should be in the package, and burned on CDs along with the package, so you can verify them more easily. Creating them by an untrusted system, and storing them on writable media (even temporarily) is a process which is difficult to harden. In contrast, i

Re: packages without .md5sums file?

On Fri, 27 Jul 2001, Wichert Akkerman wrote: > Previously Marcus Brinkmann wrote: > > Can you elaborate on the advantage of letting everyone generate their own > > checksums for the installed files? Seems to me a waste of cpu cycles. > > We process all the data in a pipe anyway so calculating the

Re: packages without .md5sums file?

Previously Marcus Brinkmann wrote: > Can you elaborate on the advantage of letting everyone generate their own > checksums for the installed files? Seems to me a waste of cpu cycles. We process all the data in a pipe anyway so calculating the checksum takes no effort. Benefits are we don't need t

Re: packages without .md5sums file?

On Fri, Jul 27, 2001 at 01:07:37PM +0200, Wichert Akkerman wrote: > No. .md5sums are the wrong approach for this. The right approach is > a combination of signing packages themselves, and dpkg generating (multiple) > checksums on the fly when installing a packages. The signin

Re: packages without .md5sums file?

Previously Massimo Dal Zotto wrote: > Is this allowed by policy? Yes. > And if not should we change the policy and require that every package have > the .md5sums file? No. .md5sums are the wrong approach for this. The right approach is a combination of signing packages themselves,

packages without .md5sums file?

Hi, I have noticed that many packages don't have the .md5sums file, for example http://http.us.debian.org/debian/pool/main/a/ae/ae_962-30_i386.deb. Is this allowed by policy? And if not should we change the policy and require that every package have the .md5sums file? -- Massimo Dal

Bug#66357: marked as done (No MD5sums for (most) base files)

Your message dated Thu, 29 Jun 2000 13:04:13 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#66357: No MD5sums for (most) base files has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the c

Processed: Re: Bug#66357: No MD5sums for (most) base files

Processing commands for [EMAIL PROTECTED]: > severity 66357 normal Bug#66357: No MD5sums for (most) base files Severity set to `normal'. > reassign 66357 debian-policy Bug#66357: No MD5sums for (most) base files Bug reassigned from package `base' to `debian-policy'. > th

Re: md5sums

omething I could run to see what files from Debian packages no longer match the distributed versions, I would definitely use it on a regular basis. dpkg --unpack and compare doesn't come anywhere close, unless it's highly automated. Even if it is, it still does several times as much di

Re: md5sums

ree, and I'm trying to avoid becoming dependent on new bits of non-free software.) Apart from being non-free, it doesn't seem to be quite the tool I want; it checks (I gather) against a previously recorded state of the system, not against the contents of the packages the system was installe

Re: md5sums

Manoj Srivastava <[EMAIL PROTECTED]> writes: > Trip wire does that. [ ... ] > Congratulations. You have just reinvented tripwire. more or less. I'd just like to point out, in case anyone had forgotten, that tripwire isn't free software. -- James

Re: md5sums

Hi, >>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: Charles> Hi all, Charles> A few thoughts about these md5sums files: Charles> First, what do we want file md5sums for? As far as I know, Charles> the point of the md5sums is to detect

Re: md5sums

Hi all, A few thoughts about these md5sums files: First, what do we want file md5sums for? As far as I know, the point of the md5sums is to detect accidental corruption of installed files: to check whether you have mistakenly edited an installed script which wasn't a conffile, or to check

Re: md5sums

Hi, >>"Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: Christoph> debsums is used for md5sums generated *before* generating Christoph> the .deb. They will detect any tampering attempts or any Christoph> other accidents in the whole packaging in and

Re: md5sums

On Tue, 1 Dec 1998, Christoph Lameter wrote: > debsums is used for md5sums generated *before* generating the .deb. They > will detect any tampering attempts or any other accidents in the whole > packaging in and out process. Its an attempt to guarantee that the files > are the way

Re: md5sums

debsums is used for md5sums generated *before* generating the .deb. They will detect any tampering attempts or any other accidents in the whole packaging in and out process. Its an attempt to guarantee that the files are the way they were on the *maintainers* system. tripwire adds md6sums *after

Re: md5sums

On Mon, Nov 30, 1998 at 10:53:38PM -0800, Ben Gertzfield wrote: > >>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: > > Joey> What do people here think about changing policy to > Joey> reccommend that packages contain a md5s

Re: md5sums

Hi, Of the packages on my system (which is an incomplete offering), these are the largest offenders are listed below (I only include a list of packages with files in the triple digits). The maount taken up by the md5sums for these files is quite considerable, espescially if

Re: md5sums

Hi, >>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> What do people here think about changing policy to reccommend Joey> that packages contain a md5sums file? The big reason to add it Joey> to policy is to make the tools that use it (debsums, mainly)

Re: md5sums

Joey Hess <[EMAIL PROTECTED]> writes: > I currently have the 4th and 8th slowest linux machines listed in the > BogoMips HOWTO: > >Intel 286 Tandy 0.75 Joey Hess <[EMAIL PROTECTED]> >Intel 386 PS2 2.34 Joey Hess <[EMAIL PROTECTED]> That's the 8th slowest? Wow.

Re: md5sums

Previously Ben Gertzfield wrote: > Sure, but including a tiny md5sums file in with the package is pretty > simple and requires very little effort on everyone's part. Not everyone wants to use md5sums probably, since breaking them is becoming feasible at the moment. It might be better

Re: md5sums

Dear Ben, I think putting the md5sums in the package sounds like a good thing -- should dpkg-buildpackage do it? > Anyone have "Debian on a super-slow machine" stories they care to > share? ;) My slowest was a 386 DX/40. Sure: all through '93 my debian developer's sys

Re: md5sums

Jason Gunthorpe wrote: > Optional perhaps? md5 hashing chews up a minor amount of time compared to > the actuall disk io, especially when you do it as the data is flowing into > the file you are writing. I'll belive the author of apt knows what he's talking about on this one. :-) > Putting it in

Re: md5sums

>>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: Ben> I believe this has been discussed before, and the general Ben> consensus was that dpkg is slow enough already as it is; Ben> generating md5sums on the fly, while it would be a g

Re: md5sums

On 30 Nov 1998, Ben Gertzfield wrote: > >>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: > > Joey> What do people here think about changing policy to > Joey> reccommend that packages contain a md5sums file? The md5sums >

Re: md5sums

>>>>> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: Joey> What do people here think about changing policy to Joey> reccommend that packages contain a md5sums file? The md5sums Joey> files have been around for over a year now, there

Re: md5sums

On Mon, 30 Nov 1998, Joey Hess wrote: > What do people here think about changing policy to reccommend that packages > contain a md5sums file? The md5sums files have been around for over a year > now, there is a well defined file format, tools to use it and generate it. > The big reas

md5sums

What do people here think about changing policy to reccommend that packages contain a md5sums file? The md5sums files have been around for over a year now, there is a well defined file format, tools to use it and generate it. The big reason to add it to policy is to make the tools that use it

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

On Wed, Feb 11, 1998 at 09:42:06AM -0600, Manoj Srivastava wrote: > Tommi> BTW, I hope lintian will check that all the suid files are > Tommi> registered with suidmanager.. > Say what? When did this become policy? Uh-oh.. it isn't. It's a personal preference. Not necessaril

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

Hi, >>"Tommi" == Tommi Virtanen <[EMAIL PROTECTED]> writes: Tommi> BTW, I hope lintian will check that all the suid files are Tommi> registered with suidmanager.. Say what? When did this become policy? manoj __> dpkg -l suidmanager pn suidmanager (no description

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

[EMAIL PROTECTED] (Rob Browning) wrote on 09.02.98 in <[EMAIL PROTECTED]>: > Christian Schwarz <[EMAIL PROTECTED]> writes: > > > Note, that md5sums was only introduced by deb-make some time ago and never > > has been widely discussed. AFAIR, a better solution than

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

On Tue, Feb 10, 1998 at 12:40:17AM -0600, Rob Browning wrote: > > Of course, a better solution would be something akin to > > suidmanager -- those packages that need it would use it, > > less important, non-critical, wouldn't. > Actually, thinking about it, since we have strict rules ab

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

Tommi Virtanen <[EMAIL PROTECTED]> writes: > Of course, a better solution would be something akin to > suidmanager -- those packages that need it would use it, > less important, non-critical, wouldn't. Actually, thinking about it, since we have strict rules about default permiss

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

On Mon, Feb 09, 1998 at 04:10:29PM -0600, Rob Browning wrote: > > Note, that md5sums was only introduced by deb-make some time ago and never > > has been widely discussed. AFAIR, a better solution than md5sums files > > would be to store more information about the unpacke

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

Christian Schwarz <[EMAIL PROTECTED]> writes: > Note, that md5sums was only introduced by deb-make some time ago and never > has been widely discussed. AFAIR, a better solution than md5sums files > would be to store more information about the unpacked files, as setuid > bits, e

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

[I CC: this to debian-devel since I think this is of public intrest. Please send any follow ups _only_ to debian-policy.] On Mon, 9 Feb 1998, Joey Hess wrote: > More problems I'm seeing as a view the lintian output - > > The lack of an md5sums file is flagged as an error. Ho

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

James Troup wrote: > No it's not. None of my packages have md5sums, and lintian didn't > complain about it. (Though it did rather amusingly complain about the > fact that the ed package dared to include /bin/ed (``name-space > pollution'') Hhehe.. Oh, I see -

Re: md5sums files (was Re: over 30000 bugs in our archive (!))

Joey Hess <[EMAIL PROTECTED]> writes: > The lack of an md5sums file is flagged as an error. No it's not. None of my packages have md5sums, and lintian didn't complain about it. (Though it did rather amusingly complain about the fact that the ed package dared to include /b

md5sums files (was Re: over 30000 bugs in our archive (!))

More problems I'm seeing as a view the lintian output - The lack of an md5sums file is flagged as an error. However, I'm not aware of any policy that says we need one. I personally like the md5sums files, but I thought lintian was bound by policy, so why is it reporting this as a

Re: are md5sums mandatory for all packages?

Scott Ellis <[EMAIL PROTECTED]> writes: > And the instant someone provides us with free software equivilant to > ssh or pgp, we'll move to use it. Really? Would that be as ``instantaneously'' as we've moved to a free MTA? > As for qmail, when it was set up we believed the final product would >

Re: free PGP (Was: Re: are md5sums mandatory for all packages?)

On Sun, Dec 21 1997 13:33 +0200 Kai Henningsen writes: > You _do_ know that there's a free PGP version, right? (The "u[i[n]]" > series.) See the international PGP home page. It's derived from very early > PGP versions that were still free. Incidentally, the guy who did the last > hacks on it li

Re: MD5SUMs in debs / dpkg install hook (new thought)

[EMAIL PROTECTED] (Hamish Moffatt) wrote on 20.12.97 in <[EMAIL PROTECTED]>: > of non-official sites. Does dpkg check the MD5sum with > the one in the Packages file or in the archive itself? I think dpkg-mountable does. At least it always tells me which packages pass a MD5 check before even st

free PGP (Was: Re: are md5sums mandatory for all packages?)

[EMAIL PROTECTED] (Scott Ellis) wrote on 19.12.97 in <[EMAIL PROTECTED]>: > And the instant someone provides us with free software equivilant to ssh > or pgp, we'll move to use it. We need the functionality, unfortunatly > sometimes you have to use what you can get. You _do_ know that there's a

Re: are md5sums mandatory for all packages?

On Sun, 21 Dec 1997, Hamish Moffatt wrote: > On Sat, Dec 20, 1997 at 07:02:45PM +0100, David Frey wrote: > > On Sat, Dec 20 1997 16:17 +1100 Hamish Moffatt writes: > > > On Fri, Dec 19, 1997 at 01:31:38PM -0500, Scott Ellis wrote: > > > > And the instant someone provides us with free software equi

Re: Free software replacements for PGP and SSH (was: Re: are md5sums mandatory for all packages?)

Regarding "Re: Free software replacements for PGP and SSH (was: R" of 03:17 AM -0800 1997-12-21, Hamish Moffatt wrote: >On Sat, Dec 20, 1997 at 06:44:31PM -0800, Joel Klecker wrote: >> The PGP replacement is called G10, and the web page for that is at >> . >>

Re: Free software replacements for PGP and SSH (was: Re: are md5sums mandatory for all packages?)

On Sat, Dec 20, 1997 at 06:44:31PM -0800, Joel Klecker wrote: > The PGP replacement is called G10, and the web page for that is at > . > Here is the status from the web page: Sounds good, although it didn't get anywhere near compiling on my libc6 system unfor

Free software replacements for PGP and SSH (was: Re: are md5sums mandatory for all packages?)

-BEGIN PGP SIGNED MESSAGE- Regarding "Re: are md5sums mandatory for all packages?" of 10:31 AM -0800 1997-12-19, Scott Ellis wrote: >And the instant someone provides us with free software equivilant to ssh >or pgp, we'll move to use it. We need the functionality, un

Re: are md5sums mandatory for all packages?

On Sat, Dec 20, 1997 at 07:02:45PM +0100, David Frey wrote: > On Sat, Dec 20 1997 16:17 +1100 Hamish Moffatt writes: > > On Fri, Dec 19, 1997 at 01:31:38PM -0500, Scott Ellis wrote: > > > And the instant someone provides us with free software equivilant to ssh > > > or pgp, we'll move to use it. W

Re: are md5sums mandatory for all packages?

This is starting to lose policy relevance (if someone doesn't volunteer to do out-of-us kerberos, it won't *be* an option, even if someone does volunteer to setup a us-only site [or manage a directory on the mpj site -- as long as I don't have to do anything more than "dupload" I don't care which,

Re: are md5sums mandatory for all packages?

On Sat, Dec 20 1997 16:17 +1100 Hamish Moffatt writes: > On Fri, Dec 19, 1997 at 01:31:38PM -0500, Scott Ellis wrote: > > And the instant someone provides us with free software equivilant to ssh > > or pgp, we'll move to use it. We need the functionality, unfortunatly > > sometimes you have to use

another use of md5sums

On Fri, Dec 19, 1997 at 01:28:52PM -0500, Mark W. Eichin wrote: > 1) a hardware flake out [computer at a residential site with >poor environment control, cheap IDE disks -- you know, what most >developers have, as well as many users] that *seems* to have recovered >cleanly. > 2) running

Re: MD5SUMs in debs / dpkg install hook (new thought)

he package >> itself works as is and there would be not much extra benefit from >> having the md5sums in the package, though the MD5SUMs should still >> be there. Maybe they could be calculated at installation time >> (this would affect performace obviously), but it would b

Re: are md5sums mandatory for all packages?

d, I think that maintainer's signatures are Fabrizio> essential for the Debian Installer to certify the origin and Fabrizio> integrity of the uploaded things, but could give a fake Fabrizio> security if checked by users later (maybe months later) on Fabrizio> installed systems.

Re: are md5sums mandatory for all packages?

Hi, >>"Joel" == Joel Klecker <[EMAIL PROTECTED]> writes: Joel> -BEGIN PGP SIGNED MESSAGE- Joel> Regarding "Re: are md5sums mandatory for all packages?" of 10:31 Joel> AM -0800 1997-12-19, Scott Ellis wrote: >> And the instant someone prov

Re: MD5SUMs in debs / dpkg install hook (new thought)

On Fri, Dec 19, 1997 at 03:12:37PM +1300, Radu Duta wrote: > What I'm thinking is that maybe it should be the responsability of dpkg, > since it is the package manager after all. The package itself works as > is and there would be not much extra benefit from having the md5sums in

Re: are md5sums mandatory for all packages?

On Fri, Dec 19, 1997 at 01:31:38PM -0500, Scott Ellis wrote: > And the instant someone provides us with free software equivilant to ssh > or pgp, we'll move to use it. We need the functionality, unfortunatly > sometimes you have to use what you can get. Hmmm. Perhaps this is a flaw in the non-US

Re: are md5sums mandatory for all packages?

> Kerberos is free software and it is more than equivalent to ssh. It also > has the advantage of being a standards track protocol (RFC 1510). It also has the disadvantage of being developed in the US. I *have* Kerberos V5 debian packages; one of the last things I did at Cygnus was to check a de

Re: are md5sums mandatory for all packages?

Manoj Srivastava wrote: > > All right, I think I a beginning to agree. Maybe dpkg *should > have integrity checking (as well as permission and ownership being > recorded record [in the .list file maybe?] -- like a ls -al listing) I am always annoyed by having dpkg -c and dpkg -L use a d

Re: are md5sums mandatory for all packages?

-BEGIN PGP SIGNED MESSAGE- Regarding "Re: are md5sums mandatory for all packages?" of 10:31 AM -0800 1997-12-19, Scott Ellis wrote: >And the instant someone provides us with free software equivilant to ssh >or pgp, we'll move to use it. Kerberos is free softwar

Re: are md5sums mandatory for all packages?

Hi, All right, I think I a beginning to agree. Maybe dpkg *should have integrity checking (as well as permission and ownership being recorded record [in the .list file maybe?] -- like a ls -al listing) If per file mdsums are to be recorded, then maybe hte too should be pgp-sign

Re: are md5sums mandatory for all packages?

On 19 Dec 1997, James Troup wrote: > Milan Zamazal <[EMAIL PROTECTED]> writes: > > > > I still fail to see any advantages in what even you admit is a > > > half baked security solution. There is a better, more secure, real > > > solution in terms of tripwire. > > > > But we have none -- tripwire

Re: are md5sums mandatory for all packages?

Indeed, I've waited for this feature simply *because* it gives me a comfortable feeling if the md5sums still check after 1) a hardware flake out [computer at a residential site with poor environment control, cheap IDE disks -- you know, what most developers have, as well as many

Re: are md5sums mandatory for all packages?

MS: secure, real solution in terms of tripwire. > > But we have none -- tripwire is non-free software. > > Dpkg md5sums could be more simple for a user (just typing > `dpkg --check-md5sums'). On my home system I'm not interested in > security, I may only want to ch

Re: are md5sums mandatory for all packages?

Milan Zamazal <[EMAIL PROTECTED]> writes: > > I still fail to see any advantages in what even you admit is a > > half baked security solution. There is a better, more secure, real > > solution in terms of tripwire. > > But we have none -- tripwire is non-free software. When has that ever stopped

Re: are md5sums mandatory for all packages?

ve none -- tripwire is non-free software. Dpkg md5sums could be more simple for a user (just typing `dpkg --check-md5sums'). On my home system I'm not interested in security, I may only want to check the system e.g. after some HW accident. I don't know whether such a thing is much us

MD5SUMs in debs / dpkg install hook (new thought)

as is and there would be not much extra benefit from having the md5sums in the package, though the MD5SUMs should still be there. Maybe they could be calculated at installation time (this would affect performace obviously), but it would be right thing to do. Another alternative is to put a hook i

Re: are md5sums mandatory for all packages?

to see why tripwire can't do that. Also, in my experience, there is a high corelation between conf files I really care about and conf files I tend to modify. Once I modify a conf file, the per package md5sum is useless (tripwire would still detect subsequent modifications). Anyway,

Re: are md5sums mandatory for all packages?

On Thu, Dec 18, 1997 at 02:19:07AM -0600, Manoj Srivastava wrote: >Radu> Hmm, well my intention for the md5sums is a bit different. I'd >Radu> like to use them to 1)check package integrity, and 2)check for >Radu> modified configuration files. Tripwire is fine, and you

Re: are md5sums mandatory for all packages?

Hi, >>"Radu" == Radu Duta <[EMAIL PROTECTED]> writes: Radu> On Tue, Dec 16, 1997 at 11:46:29PM -0600, Manoj Srivastava Radu> wrote: >> The adddition of the md5sums has come up before. Personally, I >> think the utility is limited, given the presence of

Re: are md5sums mandatory for all packages?

On Tue, Dec 16, 1997 at 11:46:29PM -0600, Manoj Srivastava wrote: > > The adddition of the md5sums has come up before. Personally, I > think the utility is limited, given the presence of tripwire, which > goes much further to ensure the integrity of the system (For example:

Re: are md5sums mandatory for all packages?

Hi, [Moving the discussion over to the policy list] The adddition of the md5sums has come up before. Personally, I think the utility is limited, given the presence of tripwire, which goes much further to ensure the integrity of the system (For example: a bad guy changes /usr

Re: are md5sums mandatory for all packages?

[I've moved this discussion to debian-policy. Please remove the CC to debian-private when replying.] On Tue, 16 Dec 1997, Radu Duta wrote: > I just ran these two commands. > > # ls -al /var/lib/dpkg/info/*.md5sums | wc > 93 8378367 > > # ls -al /var/l