Daniel Kahn Gillmor wrote:
On 09/22/2014 04:06 PM, Hans-Christoph Steiner wrote:
I think we're starting to nail down the moving parts here, so I want to
outline that so we can find out the parts where we agree and where we
disagree.
* I hope we can all agree that the package itself should
Daniel Kahn Gillmor wrote:
Thanks for the discussion, Hans.
On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
Packages should not be accepted into any official repo, sid included, without
some verification builds. A .deb should remain unchanged once it is accepted
into any official
On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
* the signature files sign the package contents, not the hash of
whole .deb file (i.e. control.tar.gz and data.tar.gz).
So preinst and friends would not be signed? Sounds dangerous to me.
--
To UNSUBSCRIBE, email to
Am 22.09.14 um 01:52 schrieb Paul Wise:
On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:
A package with some new signatures added is no more the old package.
That is exactly what we do *not* want for reproducible builds.
It should have a different checksum and be made
On 09/22/2014 04:07 AM, Elmar Stellnberger wrote:
Am 22.09.14 um 01:52 schrieb Paul Wise:
The Debian archive does not allow files to change their checksum, so
every signature addition requires a new version number. That sounds
like a bad idea to me.
Yes, that is something we definitely do
On 09/21/2014 02:04 PM, Elmar Stellnberger wrote:
a well programmed dpkg-cmp.
... and as long as the tool should not be available simply un-ar and
compare
the data.tar.gz-s.
fwiw, this suggestion fails to compare the contents of control.tar.gz,
which includes the maintainer scripts (preinst,
A package with some new signatures added is no more the old package.
It should have a different checksum and be made available again for update.
Perhaps someone wants to install the package not before certain signatures
have been added.
Your thought experiment would this way of course
On 2014-09-21 20:04, Elmar Stellnberger wrote:
A package with some new signatures added is no more the old package.
It should have a different checksum and be made available again for update.
Perhaps someone wants to install the package not before certain signatures
have been added.
If a
On 21 sep. 2014, at 20:29, W. Martin Borgert deba...@debian.org wrote:
If a package would change by adding another signature, then this
would invalidate previous signatures.
Package formats like apk and jar avoid this chicken and egg problem by hashing
the files inside a package, and storing
On 2014-09-21 21:13, Richard van den Berg wrote:
Package formats like apk and jar avoid this chicken and egg problem by
hashing the files inside a package, and storing those hashes in a manifest
file.
Is there a chicken and egg problem? Only if one insists on embedding
the signatures in one
On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:
A package with some new signatures added is no more the old package.
That is exactly what we do *not* want for reproducible builds.
It should have a different checksum and be made available again for update.
The Debian archive
On Mon, Sep 22, 2014 at 7:52 AM, Paul Wise wrote:
Reproducible builds and independent verification of those builds by
multiple parties...
sigh... is an essential feature for any operating system in today's
security climate.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE,
On 09/19/2014 06:07 AM, Elmar Stellnberger wrote:
Isn`t there really any way to include the signatures in the header of
the .deb files?
Why not simply add multiple signature files in the control.tar.gz of a
.deb just next
to the md5sums which should in deed be a sha256sums (otherwise there
On 09/19/2014 12:34 AM, Paul Wise wrote:
On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote:
Finally did this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153
Please note that you proposal to add signatures to .deb files will
break reproducible builds because the hash
14 matches
Mail list logo
