Re: concrete steps for improving apt downloading security and privacy
Am 19.09.14 um 06:34 schrieb Paul Wise: 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 of the .deb will differ depending on who signed it: https://wiki.debian.org/ReproducibleBuilds I think it would be far better to ship detached signatures in the archive since that allows for reproducible builds and also means there could be more than one signer (say one buildd, one Debian sponsor and one package maintainer). 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 is no way to establish a 'chain of trust'). That would not add any non-determinism because if it is done right then we can have all the signers in the package! It would be far better than detaching the signatures from the package because the general use case where you need package signatures is the manual download of packages. Detached signatures are completely useless for such a use case! -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541c005d.2010...@gmail.com
Re: [SECURITY] [DSA 3025-2] apt regression update
UNSUBSCRIBE! The instructions tu unsubscribe are in the footer of every mail in the mailing list. -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xuili-00039r...@master.debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919124330.gb3...@who.void
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
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 is no way to establish a 'chain of trust'). That would not add any non-determinism because if it is done right then we can have all the signers in the package! If we succeed in creating reproducible builds (we're farther along toward that goal than i had dared hope, it's exciting!) then one of the nice opportunites we have is for other people or organizations to corroborate the build after the package is first distributed. For example, an upload to sid might have one signature (by the original uploader), but maybe it waits to transition to testing until there are corroborations from multiple builders. (Note: this is not a concrete proposal or an expectation of exactly what will happen, just a thought experiment) In this scenario, how do you propose to add those signatures into the package? If we bundle them into the .deb, then the size and digest of the .deb itself changes after it is first distributed. This seems like it would violate all sorts of existing expectations -- i can't imagine how many different tools and pieces of infrastructure expect that foo_1.2-3_mipsel.deb should always have the same size and digest. It would be far better than detaching the signatures from the package because the general use case where you need package signatures is the manual download of packages. Detached signatures are completely useless for such a use case! I don't think this is the case. People who download a .deb and verify it could also download the associated .buildinfo file and whichever signatures they'd like (or all of them) and verify the package that way. --dkg signature.asc Description: OpenPGP digital signature
Bug#762214: security-tracker: sort Available releases view correctly
package: security-tracker
severity: minor
Hi,
the attached non-intrusive patch basically rewrites the availableRelease()
function which is only used to create
https://security-tracker.debian.org/tracker/data/releases which currently
is not ordered at all. The patch makes it logically by release, subrelease
and archive.
Shall I push this patch into SVN?
cheers,
Holger, finally finished chasing what he thought was a low hanging
fruit ;)
From f1841ee6be909cd6c8e8c8bf94385edf9637954f Mon Sep 17 00:00:00 2001
From: Holger Levsen hol...@layer-acht.org
Date: Fri, 19 Sep 2014 17:02:36 +0200
Subject: [PATCH] rewrite DB.availableReleases() to make it possible to sort by
release, subrelease and archive
---
bin/tracker_service.py| 2 ++
lib/python/security_db.py | 49 +++
2 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/bin/tracker_service.py b/bin/tracker_service.py
index 4ad08be..4e87dc1 100644
--- a/bin/tracker_service.py
+++ b/bin/tracker_service.py
@@ -1141,6 +1141,8 @@ not unimportant.),
sources = 'yes'
else:
sources = 'no'
+if 'source' in archs:
+archs.remove('source')
yield rel, subrel, archive, sources, make_list(archs)
return self.create_page(
url, Available releases,
diff --git a/lib/python/security_db.py b/lib/python/security_db.py
index 4917b46..1abfb8a 100644
--- a/lib/python/security_db.py
+++ b/lib/python/security_db.py
@@ -440,6 +440,14 @@ class DB:
return -1
self.db.createscalarfunction(subrelease_to_number, subrelease_to_number, 1)
+archives = ['main', 'contrib', 'non-free']
+def archive_to_number(u):
+try:
+return archives.index(u)
+except ValueError:
+return -1
+self.db.createscalarfunction(archive_to_number, archive_to_number, 1)
+
def release_name(release, subrelease, archive):
if archive 'main':
release = release + '/' + archive
@@ -451,6 +459,10 @@ class DB:
self.db.createcollation(version, debian_support.version_compare)
+def source_arch():
+return source
+self.db.createscalarfunction(source_arch, source_arch, 0)
+
def filePrint(self, filename):
Returns a fingerprint string for filename.
@@ -860,24 +872,27 @@ class DB:
if cursor is None:
cursor = self.cursor()
-releases = {}
-for r in cursor.execute(
-SELECT DISTINCT release, subrelease, archive
-FROM source_packages):
-releases[r] = (True, [])
-
-for (rel, subrel, archive, archs) in cursor.execute(
-SELECT DISTINCT release, subrelease, archive, archs
-FROM binary_packages):
-key = (rel, subrel, archive)
-if not releases.has_key(key):
-releases[key] = (False, [])
-releases[key][1][:] = mergeLists(releases[key][1], archs)
-
result = []
-for ((rel, subrel, archive), (sources, archs)) in releases.items():
-result.append((rel, subrel, archive, sources, archs))
-result.sort()
+result.append(('', '', '', False, []))
+for (rel, subrel, archive, archs) in cursor.execute(
+SELECT * FROM
+(SELECT DISTINCT release, subrelease, archive, archs
+FROM binary_packages
+UNION SELECT DISTINCT release, subrelease, archive, source_arch() as archs
+FROM source_packages)
+ORDER BY release_to_number(release), subrelease_to_number(subrelease), archive_to_number(archive)):
+ if source in archs:
+ sources=True
+else:
+sources=False
+(p_rel, p_subrel, p_archive, p_sources, p_archs) = result.pop()
+if rel == p_rel and subrel == p_subrel and archive == p_archive:
+sources = sources or p_sources
+result.append((rel, subrel, archive, sources, mergeLists(p_archs, archs)))
+else:
+result.append((p_rel, p_subrel, p_archive, p_sources, mergeLists([], p_archs)))
+result.append((rel, subrel, archive, sources, mergeLists([], archs)))
+result.pop(0)
return result
--
1.9.1
signature.asc
Description: This is a digitally signed message part.
Bug#664866: patch for: Include squeeze- and wheezy-backports in issue and package views. (Closes: #664866)
Hi Salvatore, On Donnerstag, 18. September 2014, Salvatore Bonaccorso wrote: Disclaimer, only gave a quick look. Thanks again for the work :). :-) I noticed when checking some random packages, that the version information tough is not correct. I take again the bind9 example for CVE-2014-0591. yes, I'm aware of this. I guess this is not directly a problem of the patch, but more what it uncovers? yes Without having digged into it: Is the problem that when backports is now considered as a subrelease, we will have the sorting of the versions no, it's that the bug tables don't know about backports already... I'll work on a fix shortly... (I use+maintain backports myself, so I'm interested in correct functionality.) Thus for now (clearly) I'm not sure we really should include -backports ... yes, though https://security-tracker.debian.org/tracker/status/release/stable-backports https://security-tracker.debian.org/tracker/status/release/oldstable-backports already exist and are broken. It would be trivial to disable/hide them, but I'm really more interested in fixing them. On a related note, I've also reworked the selection logic on those status/release/$RELEASE views and replace those link logic with proper checkboxes (so one can select to only view high or low urgency bugs or whatever) and in future there could be checkboxes for sloopy-backports instead of regular ones, or the inclusion/exclusion of proposed updates. cheers, Holger signature.asc Description: This is a digitally signed message part.
