* David Kalnischkies , 2014-06-18, 14:11:
[0] And his skepticism was reinforced by (independent) discovery of
this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738
*sigh* and this is still open? 8-O
Before someone is rushing to work on that (sorry, I was dreaming)… we
actua
Christoph Anton Mitterer dijo [Fri, Jun 20, 2014 at 10:24:07PM +0200]:
> > I do feel the keyring-maint package is a leftover from days long
> > gone. Nowadays the keyring is kept at a DVCS tree, and regularly
> > exported to a publicly accessible instance.
> Any reason for that "internal" repo? I m
Raphael Hertzog dijo [Fri, Jun 20, 2014 at 09:17:25AM +0200]:
> > FWIW, I was thinking about including the possible disappearance as one
> > of the points to talk about in the DebConf BoF we proposed regarding
> > keyring-maint.
>
> Why not switch it to something more dynamic ?
>
> Make the packa
On Tue, Jun 24, 2014 at 11:26:43AM +0200, Philipp Kern wrote:
[..snip..]
> [1] I'm aware that certain libraries do restart services affected by the
> upgrade, but there's no generic framework for this.
whatmaps[A] hooks into the apt pipeline for that and looks for shared
objects coming in via secu
On 2014-06-23 17:33, Christoph Anton Mitterer wrote:
Well I just think that most of the time, our Security Team does some
very great job (if not hiding away issues o.O) and fixes are available
in Debian very shortly after a fix is available.
These guys put a lot effort into that, but their quick
* Adam D. Barratt , 2014-06-23, 14:24:
* Christoph Anton Mitterer , 2014-06-22, 04:34:
There are a few mechanisms to mitigate downgrade attacks within
the archive:
* Valid-Until fields in the Release files;
I still think the time spans are far too long here...
For the record, the validity pe
For the interested:
On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote:
> "reportbug ftp.debian.org" for unstable and experimental;
#752450
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote:
> For the record, the validity periods currently are:
>
> unstable, experimental: 7 days
> testing: 7 days
>
> wheezy: no limit
> wheezy(-proposed)-updates: 7 days
> wheezy/updates at security.d.o: 10 days
> wheezy-backports: 7 days
>
> squee
On 2014-06-23 13:42, Jakub Wilk wrote:
* Christoph Anton Mitterer , 2014-06-22, 04:34:
There are a few mechanisms to mitigate downgrade attacks within the
archive:
* Valid-Until fields in the Release files;
I still think the time spans are far too long here...
For the record, the validity pe
* Christoph Anton Mitterer , 2014-06-22, 04:34:
There are a few mechanisms to mitigate downgrade attacks within the
archive:
* Valid-Until fields in the Release files;
I still think the time spans are far too long here...
For the record, the validity periods currently are:
unstable, experime
Hi Christoph,
On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote:
> To be honest, Holger, I don't know why you've asked me to report these
> issues at all, [...]
so they are tracked and easy to be referenced - #752275 is way better than
several message-ids on lists.d.o.
> But now I just
On Sun, 2014-06-22 at 12:27 +0200, Holger Levsen wrote:
> On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote:
> > > one or two bug reports might be oh so more useful than posting on -devel.
> > #752275 and #752277
>
> thanks for these!
To be honest, Holger, I don't know why you've asked m
Hi Christoph,
On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote:
> > one or two bug reports might be oh so more useful than posting on -devel.
> #752275 and #752277
thanks for these!
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
On Wed, 2014-06-18 at 13:55 +0200, Jakub Wilk wrote:
> Yes, maintaining packages properly takes time. If packaging new upstream
> releases is too much effort, why bother uploading it to Debian in the
> first place?
Actually, I think everything that tries to circumvent the package
management syst
FYI: On Wed, 2014-06-18 at 12:46 +0200, Holger Levsen wrote:
> one or two bug reports might be oh so more useful than posting on -devel.
#752275 and #752277
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Hey Holger,
On Wed, 2014-06-18 at 12:46 +0200, Holger Levsen wrote:
> > It also doesn't seem to protect against downgrading attacks... (see my
> > previous post about that).
> one or two bug reports might be oh so more useful than posting on -devel.
I will submit tickets for the ones I know (as s
On Fri, 2014-06-20 at 09:17 +0200, Raphael Hertzog wrote:
> Why not switch it to something more dynamic ?
Sounds good...
> Make the package an empty shell with symlinks pointing to
> /var/lib/debian-keyring/, add a cron job that rsyncs the keyring
> to that directory.
I've just thought about th
On Thu, 2014-06-19 at 21:25 -0500, Gunnar Wolf wrote:
> Thanks for bringing this topic up. I'm snipping your very detailed
> implementation proposal, which does not sound like it was written at
> 4AM at all ;-)
;-)
> I do feel the keyring-maint package is a leftover from days long
> gone. Nowada
On Tue, 2014-06-17 at 10:48 +0200, David Kalnischkies wrote:
> On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote:
> > Erm, no? You can just cache a working Sources file and exchange
> > the paragraph you are interested in. That’s something that would
> > be easy in a CGI written in s
Hi,
On Thu, 19 Jun 2014, Gunnar Wolf wrote:
> FWIW, I was thinking about including the possible disappearance as one
> of the points to talk about in the DebConf BoF we proposed regarding
> keyring-maint.
Why not switch it to something more dynamic ?
Make the package an empty shell with symlinks
Christoph Anton Mitterer dijo [Wed, Jun 18, 2014 at 04:21:36AM +0200]:
> On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote:
> > debian-keyring is not useful for automatic authentication of source
> > packages.
> Well to be honest I never fully understood the idea behind
> debian-keyring...
> IM
(so not going to comment on the first part of the thread, beside maybe:
Its really sad that it is even suggested that DDs would need a technical
solution for the inherently social problem of a co-worker dying…)
On Wed, Jun 18, 2014 at 04:21:36AM +0200, Christoph Anton Mitterer wrote:
> On Mon, 201
* Holger Levsen , 2014-06-18, 12:46:
usually one should depend on a fixed hash in such downloader
packages... doing it with gpg is securely possible, but much more
complicated.
and then for each update you need to update the launcher package -
thats an aweful lot of work for little / no gain
Hi,
On Mittwoch, 18. Juni 2014, Christoph Anton Mitterer wrote:
> torbrowser-launcher seems to use the keys from the upstream
> developers... basically giving them (who are not DDs) the potential
> power to install _any_ code in the system of Debian users.
fun fact: there's at least one DD among
On Tue, 2014-06-17 at 13:39 +0200, Holger Levsen wrote:
> > Well I guess the reason for flash is rather the license, isn't it?
> no, it's in contrib, because it's a downloader package.
Well sure... but flash itself is not in main for it's license...
> both torbrowser-launcher as well as flashplu
On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote:
> debian-keyring is not useful for automatic authentication of source
> packages.
Well to be honest I never fully understood the idea behind
debian-keyring...
IMHO this should be actually debian-developers-keyring and it should be
intended just
Hi Christoph,
On Montag, 16. Juni 2014, Christoph Anton Mitterer wrote:
> Well I guess the reason for flash is rather the license, isn't it?
no, it's in contrib, because it's a downloader package.
> Anyway... just because something it in contrib/non-free for legal
> reasons... I see no necessit
On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote:
> On Thu, 12 Jun 2014, David Kalnischkies wrote:
> > For your attack to be (always) successful, you need a full-sources
> > mirror on which you modify all tarballs, so that you can build a valid
> > Sources file. You can't just build
* Christoph Anton Mitterer , 2014-06-16, 19:50:
Thomas mentioned that things would have been more secure if the buildds
and e.g. pbuilder pulls in debian-keyring automatically and verify
maintainer signatures.
debian-keyring is not useful for automatic authentication of source
packages. The s
On Thu, 2014-06-12 at 23:06 +0200, Holger Levsen wrote:
> both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib
> (and thus not be part of Debian) for exactly those reasons you described.
Well I guess the reason for flash is rather the license, isn't it?
Anyway... just bec
On Thu, 2014-06-12 at 19:43 +0100, Wookey wrote:
> So it does default to signed downloads and SFAIK will always do this
> wether or not any keys are installed/available, unless explicitly disabled.
What I meant was the discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432309
i.e.
Hey Thijs.
On Thu, 2014-06-12 at 19:31 +0200, Thijs Kinkhorst wrote:
> You raise a lot of broad concerns under the header "holes in secure apt"
> which
> I'm afraid does not much to get us closer to a more secure Debian.
Well I admit, that first this is just a lot of words... but I think
that's
On Thu, Jun 12, 2014 at 07:31:14PM +0200, Thijs Kinkhorst wrote:
> I think a better way than to create such a policy would be to create a simple
> framework that does in-package downloading "right" and that downloader
> packages can depend on and call from their scripts (a bit like dbconfig-
> co
On Thu, 12 Jun 2014, David Kalnischkies wrote:
> For your attack to be (always) successful, you need a full-sources
> mirror on which you modify all tarballs, so that you can build a valid
> Sources file. You can't just build your attack tarball on demand as the
Erm, no? You can just cache a work
At Thu, 12 Jun 2014 18:35:39 +0200,
Christoph Anton Mitterer wrote:
>
> On Thu, 2014-06-12 at 10:30 +0200, Thorsten Glaser wrote:
> > The buildd-related software (and most people when doing manual builds
> > with cowbuilder) uses “apt-get source foo” to download the file, fully
> > assuming that
Hi Christoph,
On Donnerstag, 12. Juni 2014, Christoph Anton Mitterer wrote:
[many things]
both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib
(and thus not be part of Debian) for exactly those reasons you described. And
both rightfully belong to contrib, even though tor
On Thu, 12 Jun 2014 19:43:56 +0100
Wookey wrote:
> +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> > - [c]debootstrap
> > I think they both default now to verify signatures (which is a good
> > thing)... but IIRC, debootstrap also defaults to not verify
> > anything... if the keyrings ar
Hi!
On Thu, 2014-06-12 at 19:43:56 +0100, Wookey wrote:
> +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> > - [c]debootstrap
> > I think they both default now to verify signatures (which is a good
> > thing)... but IIRC, debootstrap also defaults to not verify anything...
> > if the keyri
+++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]:
> - [c]debootstrap
> I think they both default now to verify signatures (which is a good
> thing)... but IIRC, debootstrap also defaults to not verify anything...
> if the keyrings aren't installed - admittedly this is unlikely... but
> possibl
Hi Chris,
You raise a lot of broad concerns under the header "holes in secure apt" which
I'm afraid does not much to get us closer to a more secure Debian. Not many
people will object that making Debian even more secure is a bad idea; it just
needs concrete action, not a large list of potential
On Thu, 2014-06-12 at 10:30 +0200, Thorsten Glaser wrote:
> On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
> > Anyone who believed in getting trusted sources might have been attacked
> > with forged packages, and even the plain build of such package might
> > have undermined users' security
On Thu, 2014-06-12 at 16:54 +0200, Christoph Anton Mitterer wrote:
> On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote:
> > If you want to discuss your plans to work on improving APT, you're more
> > on-topic at de...@lists.debian.org.
> I think this goes beyond
> just APT (even though APT
On Thu, Jun 12, 2014 at 01:06:28AM +0200, Christoph Anton Mitterer wrote:
> In my opinion this is really some horrible bug... probably it could have
> been very easily found by others, and we have no idea whether it was
> exploited already or not.
Probably yes. Someone in the last ~11 years could
On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote:
> > Anyone who believed in getting trusted sources might have been attacked
> > with forged packages, and even the plain build of such package might
> > have undermined users' security integrity.
> >
> > The same is the case with all debian
On Thu, 2014-06-12 at 00:07 -0400, Joey Hess wrote:
> AAICS, #749795 talked about bringing this to the security team's
> attention, but they never seem to have been CCed.
Thanks for doing that now...
> So the security team may not be aware that a security hole in apt was
> recently fixed, that c
On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
> Anyone who believed in getting trusted sources might have been attacked
> with forged packages, and even the plain build of such package might
> have undermined users' security integrity.
Then I believe Debian itself may be undermined.
> The
* Thijs Kinkhorst , 2014-06-12, 08:58:
On Thu, June 12, 2014 01:06, Christoph Anton Mitterer wrote:
reopen 749795
stop
A better way would be to add more 'found' versions so the BTS version
tracking shows this bug as affecting stable.
Indeed. "reopen" throws away information about fixed vers
Hi Chris,
On Thu, June 12, 2014 01:06, Christoph Anton Mitterer wrote:
> reopen 749795
> stop
A better way would be to add more 'found' versions so the BTS version
tracking shows this bug as affecting stable.
> Anyone who believed in getting trusted sources might have been attacked
> with forged
Christoph Anton Mitterer wrote:
> reopen 749795
> I'm reopening this for now, even if the issue is solved from a technical
> point of view (see below why).
AAICS, #749795 talked about bringing this to the security team's
attention, but they never seem to have been CCed.
So the security team may n
49 matches
Mail list logo
