On Wed, 29 Nov 2000 18:43:51 -0500, Ben Collins <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > I would prefer that *any* modification to a .deb increment its
> > version.
>
> That would be bad. Do that and then the Packages file needs regenerating,
> From: Jason Gunthorpe [mailto:[EMAIL PROTECTED]
> > Why would they want to do this? I usually run a completely
> unstable system,
> > that is rather stable BTW, so don't understand why someone
> who runs a stable
> > system would want to "lie" about a package being stable
> when, in fact, it
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> Why would they want to do this? I usually run a completely unstable system,
> that is rather stable BTW, so don't understand why someone who runs a stable
> system would want to "lie" about a package being stable when, in fact, it is
It isn't lieing, i
[Reimer, Fred - Wed, 29 Nov 2000 08:01:15 PM CST]
} > This is a common assumption and is wrong. The most popular
} > use of apt-get
} > source -b has been to make stable compiles of unstable
} > packages. Rather
} > than some source tweak.
}
} Why would they want to do this? I usually run a com
> -Original Message-
> From: Jason Gunthorpe [mailto:[EMAIL PROTECTED]
>
> > THEORETICALLY, if a user downloads the source and does a
> simple compile they
> > SHOULD get the same binaries produced as the developer did.
> This assumes
> > that they are using the standard compiler and li
On Wed, Nov 29, 2000 at 06:36:12PM -0700, Jason Gunthorpe wrote:
>
> On Wed, 29 Nov 2000, Ben Collins wrote:
>
> > > Mmkay... 9 Gb mirror pulse... that will work. (not)
> >
> > That's a seperate issue that does not pertain to the UUID's. Let's discuss
> > this later.
>
> Er, so far the only
On Wed, 29 Nov 2000, Ben Collins wrote:
> > Mmkay... 9 Gb mirror pulse... that will work. (not)
>
> That's a seperate issue that does not pertain to the UUID's. Let's discuss
> this later.
Er, so far the only reason to have a UUID that has held up to scrutiny
revolves around whatever your si
On Wed, 29 Nov 2000, Reimer, Fred wrote:
> THEORETICALLY, if a user downloads the source and does a simple compile they
> SHOULD get the same binaries produced as the developer did. This assumes
> that they are using the standard compiler and libraries in the particular
This is a common assumpt
> -Original Message-
> From: Ben Collins [mailto:[EMAIL PROTECTED]
>
> > The "easy" answer to that is that the version should
> automatically get
> > bumped for user builds much like the kernel compile # is
> for Linux. The
> > maintainers, when generating an "official" version, can
>
On Thu, Nov 30, 2000 at 12:55:36AM +, James Troup wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
> > > Good grief. This would require all non-rsync mirrors to redownload
> > > *every* .deb in the newly released distribution in whole, and
> > > would require every user to redownlo
> -Original Message-
> From: Ben Collins [mailto:[EMAIL PROTECTED]
>
> Plus pkg+version+arch is not always enough. Note (even though it is a
> bug/mistake in it's own right), there are potato/woody
> packages with the
> same version and arch, that are not the same binary. This is very
> i
>
> So you think it's easy to force users to generate a unique version number?
> How are you going to do that? If you make a debian developer pass a
> special arg, how are you going to keep users from using the same thing?
>
> Obviously it's not so easy, or it would already be done.
>
beyond th
* Reimer, Fred <[EMAIL PROTECTED]> [001129 17:03]:
> The "easy" answer to that is that the version should automatically get
> bumped for user builds much like the kernel compile # is for Linux. The
> maintainers, when generating an "official" version, can specify the exact
> version when they comp
>
> The "easy" answer to that is that the version should automatically get
> bumped for user builds much like the kernel compile # is for Linux. The
> maintainers, when generating an "official" version, can specify the exact
> version when they compile the package, but it should automatically inc
> -Original Message-
> From: Sean 'Shaleh' Perry [mailto:[EMAIL PROTECTED]
> > Sorry, I'm not a Debian developer so honestly don't know
> all the policies or
> > processes behind making debs. But, it seems clear to me
> that if you use the
> > pkg+version+arch as your UUID then a change
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
> > Good grief. This would require all non-rsync mirrors to redownload
> > *every* .deb in the newly released distribution in whole, and
> > would require every user to redownload every package they've
> > installed if they want to upgrade from foo
On Wed, 29 Nov 2000, Ben Collins wrote:
> bug/mistake in it's own right), there are potato/woody packages with the
> same version and arch, that are not the same binary. This is very
This is an archive bug and James's new scripts make it impossible.
> important from a security/signing standpoin
On Wed, Nov 29, 2000 at 04:14:25PM -0800, Joey Hess wrote:
> If I understand right, Ben wants something unique that can be signed
> for some secrit package signing scheme. Assuming the sig goes in a
> component after control.tar.gz and data.tar.gz, why can't is just sign
> a concacentation of their
On Wed, Nov 29, 2000 at 04:12:39PM -0800, Sean 'Shaleh' Perry wrote:
> > Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> > that. Maybe the official policy needs to be updated so that it is clear
> > that any change to the binary packages, including just compile time chang
>
> Good grief. This would require all non-rsync mirrors to redownload *ever*
> .deb in the newly released distribution in whole, and would require
> every user to redownload every package they've installed if they want to
> upgrade from foo-unstable to foo-stable. It'd also mean package signature
On Wed, Nov 29, 2000 at 04:12:39PM -0800, Sean 'Shaleh' Perry wrote:
> > Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> > that. Maybe the official policy needs to be updated so that it is clear
> > that any change to the binary packages, including just compile time chang
* Joey Hess <[EMAIL PROTECTED]> [001129 16:17]:
> [...] sign a concacentation of their md5sums? [...]
> I don't understand how signing a uuid that is just listed in the control
> file and could be modified by anyone is cryptographically secure.
I would like to suggest that whatever signature schem
>
> Sorry, I'm not a Debian developer so honestly don't know all the policies or
> processes behind making debs. But, it seems clear to me that if you use the
> pkg+version+arch as your UUID then a change in the md5sum caused by adding a
> signature would not effect the "UUID" and therefore be mo
> -Original Message-
> From: Sean 'Shaleh' Perry [mailto:[EMAIL PROTECTED]
> > Your UUID is the pkg+version+arch. From my viewpoint it's
> as simple as
> > that. Maybe the official policy needs to be updated so
> that it is clear
> > that any change to the binary packages, including jus
If I understand right, Ben wants something unique that can be signed
for some secrit package signing scheme. Assuming the sig goes in a
component after control.tar.gz and data.tar.gz, why can't is just sign
a concacentation of their md5sums?
I don't understand how signing a uuid that is just liste
> Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> that. Maybe the official policy needs to be updated so that it is clear
> that any change to the binary packages, including just compile time changes,
> requires a version update? That way you could change your "sigs" as
ists.debian.org; debian-policy@lists.debian.org
> Subject: Re: New field proposed, UUID
>
>
> On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > > Sooner or later sigs will start traveling around with
> .deb's (that's
> > > another discus
> From: Ben Collins [mailto:[EMAIL PROTECTED]
> > (Aside: APT internally builds a fairly reliable ID for most
> purposes,
> > some of you may have noticed that it can tell you have
> local compiles,
> > this is how.)
>
> This is a perfect example to answer your question above.
> Local builds ca
On Wed, 29 Nov 2000, Ben Collins wrote:
> That would be bad. Do that and then the Packages file needs regenerating,
> the package needs to be re-signed by everyone, and things will get upgraded,
> and apt[1] will redownload it all over again, just because of something
> changing like an internal
On Wed, 29 Nov 2000, Ben Collins wrote:
> > The pacakge file for woody/main would increase by at least 193k (16%
> > growth) and APT would consume 300k more ram on your average woody/potato
> > mix.
>
> In all likelyhood we could omit it from the Packages file. Also, apt need
> not keep it in it
On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > Sooner or later sigs will start traveling around with .deb's (that's
> > another discussion, save it for later, it is coming soon). When those sigs
> > are changed or updates by the archive maintainers or the release manager,
> > th
On Wed, Nov 29, 2000 at 03:48:21PM -0700, Jason Gunthorpe wrote:
>
> On Wed, 29 Nov 2000, Ben Collins wrote:
>
> > upgrading dpkg-dev, and poses little side-affects (other than a small
> > increase in the size of the Packages file and .deb's in general).
>
> The pacakge file for woody/main would
On Wed, 29 Nov 2000, Ben Collins wrote:
> upgrading dpkg-dev, and poses little side-affects (other than a small
> increase in the size of the Packages file and .deb's in general).
The pacakge file for woody/main would increase by at least 193k (16%
growth) and APT would consume 300k more ram on
On 29-Nov-2000 Ben Collins wrote:
> I'm proposing we add a new field to generated packages, and as part of
> Debian policy, make them required for Debian packages. It's all very
> simple, doesn't requuire any effort by the maintainers other than
> upgrading dpkg-dev, and poses little side-affects
> Sooner or later sigs will start traveling around with .deb's (that's
> another discussion, save it for later, it is coming soon). When those sigs
> are changed or updates by the archive maintainers or the release manager,
> the md5sum of the package will change, but the UUID will remain the same.
I'm proposing we add a new field to generated packages, and as part of
Debian policy, make them required for Debian packages. It's all very
simple, doesn't requuire any effort by the maintainers other than
upgrading dpkg-dev, and poses little side-affects (other than a small
increase in the size of
36 matches
Mail list logo
