[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: New field proposed, UUID

> From: Ben Collins [mailto:bcollins@debian.org]
> > (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 can
> have the same pkg+version+arch, but not be the same package. 
> Other things
> can contribute to this aswell, such as a package built by thge author
> being the same version as the one in Debian.

I would hope that "local builds" would increment the version number
appropriately or use a suffix to indicate that it's a local build.  When you
recompile the kernel do you leave the version at 2.4.0-test9, or do you
append a "-fwr1" or whatever your initials are like I do?  Isn't this
"standard practice?"  True, local builds CAN have the same pkg+versoin+arch,
but SHOULD they?  I don't think they should, as they are not the official
Debian builds.  They are a different "version" of the package, even if the
only differences are compile options used, for example.

> > > Now, you may be asking "why?". The answer is very simple. 
> We need a way to
> > > discern packages from one another for security reasons. 
> To invalidate a
> > > .deb, we need a way to discern it from others, without 
> comparing package
> > > name, filename, version, md5sum, etc...
> > 
> > If this is the only reason then why don't we defer this 
> discussion until
> > you present whatever security scheme you have in mind.
> This is one of the main reasons. No matter what the backend policy is
> behind this, we need a way to discern packages based on a UUID of
> somesort.

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 often
as you'd like but you would know that a particular build was a particular
build.  The alternative would be saying that a package that was locally
built, or otherwise was the same as the "official" version (UUID) other than
compile options, SHOULD have the same version (UUID) as official version.  I
don't believe that would be wise, as it's perfectly reasonable to suggest
that changing compile time options could open up security holes that are
otherwise not present in the official version.  I think it's clear that any
change in the binary deb, that results in a change of what exactly is
installed on a system when the package is installed, should have a different
version number.  If someone is just updating the description of a package in
the package header then that's another story, and possibly those "different"
packages should have the same version number.

Fred Reimer
Eclipsys Corporation

Reply to: