Hey.
Seems some of the reverse engineers may have found some more
interesting stuff[0].
As far as I understand it, that would still require a running an
reachable sshd (so we'd still be mostly safe).
But he also thinks[1] that it may allow an interactive session.
(Not that this would change a l
On Fri, 2024-04-05 at 20:47 +0200, Sirius:
> > If there is a final result, can we as a project share the results on a
> > prominent place? Or at least under d-devel-announce and/or d-security-
> > announce? I was also wondering about what could have been compromised,
> > what data might have been s
Hey.
On Tue, 2024-04-02 at 01:30 +0100, Colin Watson wrote:
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package: I get enough occasional
> bug
> reports to convince me that it's still in use.
Being one of those people, and having even a
On Thu, 2024-02-29 at 06:53 +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically
> works) *and* losing files is one of the problems of our merged-/usr
> solution (see [1]). I *suspect* this might be the cause. We're
> working
> hard (well, helmut is) to
On Wed, 2024-02-28 at 21:57 -0800, Steve Langasek wrote:
> Furthermore, this is a downgrade from a replacing package to a
> replaced
> package. Unless you also --reinstall the package at the end, missing
> files
> are quite to be expected.
Shouldn't that case be something that DPKG could detect an
Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-devel@lists.debian.org
Hey.
CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
revertin
Package: general
Severity: normal
Hey.
Not sure where this should actually go to (apt? ftp-masters? backports?)...
please reassign as it fits :-)
It's seems to have never properly worked for me, to use the suite-names for
backports repos in sources list.
E.g. having:
deb http://foo/debian/ o
On Fri, 2016-08-26 at 17:07 +0100, Adam D. Barratt wrote:
> No. It shows that, two years ago, over 18,000 machines that were
> reporting to the popcon servers had sysvinit-core installed and now
> less
> than a third of that number do.
Still doesn't make it in any way representative...
There cou
On Fri, 2016-08-26 at 11:02 +0100, Lars Wirzenius wrote:
> we'd check something
> like popcon stats.
I'm always kinda surprised if people rely on popcon... is it in *any
way* representative?
Plus it may not even tell the truth due to dependencies, e.g. people
using gdm3 will also have gnome-shell
On Fri, 2016-01-08 at 09:35 -0800, Russ Allbery wrote:
> Moving the goalposts from trivial MITM via a rogue AP to obtaining a
> fradulent SSL certificate is probably not "hard" security, whatever
> that
> means to you, but is a substantial increase the level of work
> required for
> the attacker.
W
On Fri, 2016-01-08 at 10:43 -0500, Paul Tagliamonte wrote:
> I'd like to suggest we move all Vcs-Git entries to either `https` or
I doubt https will give any real hard additional security, based on the
inherent problems of the X.509 CA system.
Per default, git would take the system CA store, which
On Sun, 2015-12-20 at 10:57 +0800, Paul Wise wrote:
> > Last but not least, what about security support?
> None of the suites available on it (unstable/experimental) recieve
> security updates.
Sure, but I guess, sooner or later testing/stable would be secured as
well?
> The packages on it are on
On Sat, 2015-12-19 at 23:26 +, Niels Thykier wrote:
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default!
Awesome, thx to all.
Will this eventually replace all the existing -dbg packages?
> deb http://debug.mirrors.de
Hey.
One addendum on this:
I think a further reasons why we cannot really do this (i.e. remove the
dummy wrappers for fsck.btrfs and so on) is:
Nothing really guarantees that the user wouldn't set passno back to
something non-0, after all it's still a valid value.
Maybe they just auto-deploy the
Hey.
Well the consensus over at linux-btrfs list seems to be:
1) right now it's not yet stable enough (has false positives, etc.)
2) it's very slow
3) btrfs should detect errors by itsel
and thus the suggestion tends towards "don't run it at boot".
(1) should hopefulle be resolved sooner or late
On Tue, 2015-11-24 at 03:23 +, Dimitri John Ledkov wrote:
> btrfs check is a destructive tool, that can attempt repairing btrfs
> filesystem. it should not be run automatically, nor non-interractive,
> nor on each boot.
What source is that information based on?
To my knowledge, and I think I re
On Tue, 2015-11-24 at 04:12 +0100, Christoph Anton Mitterer wrote:
> In fact, btrfs seems to be quite useful already these days...
I meant "btrfs check" ;-)
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2015-11-24 at 02:51 +, Dimitri John Ledkov wrote:
> This is currently the case for xfs and btrfs, which imho is silly.
Well sooner or later, btrfs check is declared stable and then I think
we do want to have regular checks (though don't know whether this is
upstream's recommendation).
On Wed, 2015-08-19 at 20:01 -0700, Nikolaus Rath wrote:
> Until now, I did not know how much trust I'm actually putting into
> the
> remote server when using -X (on Debian). I'll probably continue to
> use
> it in the majority of cases (because the alternatively seems rather
> useless), but in my
On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> I tried some experiments with ForwardX11Trusted=no today, and
> frankly,
> it doesn't even pass the laugh test for usability.
Well but it's ssh "Secure Shell" - and not ush (Usability Shell).
So the defaults should be always the secure ones,
On Sun, 2015-08-02 at 16:37 +0200, Daniel Pocock wrote:
> I apologize for not being more explicit, this is the sort of thing I
> was thinking too, it wouldn't be up to dpkg or postinst to guess or
> insist on a particular CA. Rather, it would be an optional prompt
> and there would be some scri
On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote:
> See previous message.
I've had read that only afterwards, as well as this message.
> You will get
> absolutely nowhere continuing to tell people that they need to drop
> everything to scratch your particular itches.
I don't think I've as
On Fri, 2015-05-29 at 16:17 +0200, Marco d'Itri wrote:
> > And I guess it's rather uncommon on Debian to use NM e.g. on server
> > systems (probably also because most people wonder why they need a
> > bloated daemon/etc. running just for a network that is brought up/down
> > once every nnn days)
>
On Thu, 2015-05-28 at 11:18 +0800, Paul Wise wrote:
> > Haven't tried systemd-networkd yet, but at least NM fails in even very
> > simple cases (like resolving is broken, when I disconnect the wire and
> > go back to wifi, etc. pp.) ... plus the whole design, that it tries to
> > be the canonical
On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote:
> I don't think ifupdown has been "Debian's native tool" for several years
> now. It is one among several available tools, and happens to be the only
> one with Debian as its upstream; on a wheezy-era sysvinit system that
> uses NetworkManag
On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
> (I am shocked, shocked that there is no flood of people here rushing to
> save ifupdown... :-) )
Perhaps people are just tired of flame wars... (for now...) ;)
However, I hope ifupdown is going to live on. Or are there any plans to
replace
On Tue, 2015-03-31 at 19:34 -0700, Nikolaus Rath wrote:
> Note that this does not seem to be due to a lack of people willing to
> work on it though, cf. #750135.
Yeah, I was following that bug in silence ;-)
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2015-03-31 at 23:18 +0200, Wouter Verhelst wrote:
> No, it is not. It used to be, but apt's dependency resolver is far
> superior to aptitude's these days.
Are there so many cases where you need it? I usually just select what I
want and install it...
IMHO aptitude is one of the hearts of
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=89092
Since that's the first good valid argument against I feel I should
answer:
On Wed, 2015-02-11 at 21:12 +, Jeremy Stanley wrote:
> My passwords will stop working. (Okay, not _mine_ specifically, but
> someone's...) Chan
On Tue, 2015-02-10 at 22:44 -0800, Russ Allbery wrote:
> Whether that was intended or not, that's not what people actually did when
> they made those keyboard layouts. They did not put the dot multiplication
> sign on that key; they put the middle dot symbol on that key.
Arguing like that, we cou
reopen 777643
stop
On Wed, 2015-02-11 at 05:08 +, Ben Hutchings wrote:
> This is speculation, not a proper bug report.
And is there any reason to name it "speculation" apart from that being
just your personal opinion without any further arguments for it?
It seems to be quite logical that act
Package: general
Severity: normal
Hey.
Sorry for reporting against general, but actually I'm not quite
sure which package(s) is/are canonically responsible for the
keyboard mappings in all different places (console, X, wayland)
these days.
Some keyboard layouts (at least the German one) give th
On Wed, 2014-12-31 at 12:04 -0800, Russ Allbery wrote:
> I think UsePAM yes is the only sane default for Debian, though, and people
> who choose to change that default are legitimately on their own.
I've used UsePAM no for many years without any real issues, as you said
it depends what you want (a
One should perhaps add:
On Wed, 2014-12-31 at 16:20 +0200, Faidon Liambotis wrote:
> - Behavior is different between login & sshd. login has (#741129):
> session optional pam_exec.so type=open_session stdout /bin/uname -snrvm
> session optional pam_motd.so
>
> but SSH has:
> session opti
On Fri, 2014-12-05 at 03:47 +0100, Enrico Weigelt, metux IT consult
wrote:
> No, it's not, and it's pretty cheap, if done right.
Yes it definitely is, because simply by having gazillions of different
users on the same host, you increase the chance that someone is doing
something stupid, which can
On Thu, 2014-12-04 at 21:14 +0100, Marco d'Itri wrote:
> While using many more times the resources. You obviously have no idea of
> the challenges of providing secure web hosting for non-trivial
> quantities of web sites.
So what do you want to imply would be secure?
Apart from that, when you s
On Thu, 2014-12-04 at 17:03 +0100, Matthias Urlichs wrote:
> If you can run a CGI inside a chroot/container/whatever, you can run a
> small web server on a local port / Unix socket, and reverse-proxy it,
> just as easily.
Well that's probably roughly the same, although I'd still feel better if
web
On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote:
> Except that if a firewall "protects" a user from using their printer
> (random example, not sure how likely)
Well most security guys are probably sceptical about any automagical
confiugration of things like a printer... so "protects" can
On Fri, 2014-11-28 at 19:05 +0100, Marc Haber wrote:
> And I am also pretty sure that they would not de-implement the Common
> Gateway Interface just because people still like to run vulnerable
> Matt Wright Scripts from 2002.
For many things, CGI is actually the only way to run them securely,
si
On Tue, 2014-11-18 at 01:26 +0100, Michael Banck wrote:
> This mailing list is a technical list and your message/question is
> off-topic. Kindly reask it on another list, or another forum
> altogether.
I wouldn't say that the two posts I was particularly replying to were in
any way more technical
On Tue, 2014-11-18 at 00:43 +0100, John Paul Adrian Glaubitz wrote:
> > This decision has been made in gross violation of constitution §6.3.6,
> > being summoned to override a maintainer’s choice while the solution
> > was still under discussion.
> >
> > I urge the systemd maintainers not to take
On Sun, 2014-11-09 at 22:38 +0100, Simon Richter wrote:
> I can completely understand why we (and that includes me) want systemd
> as a default: it gives the best possible integration of desktop
> components possible.
I even think it's best on a server (that means, if it was used as it
could be)..
On Sun, 2014-11-09 at 18:12 -0400, Joey Hess wrote:
> I've left[1]
+
>Almost.
So you still could (and perhaps should[0]) reconsider not to leave
Debian.
Guess you've read the lists and saw how many people were emotionally hit
and upset about this.
(well I think it's worth a try ^^)
Cheers,
Ch
On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote:
> No accusation, just a statement of fact. Four ctte members were
> complicit in the vote [0]
Well maybe I read that ruling wrong, but didn't it more or less say
"we're not deciding anything right now"?
And even if that decision would be
On Sat, 2014-11-08 at 22:32 -0500, Michael Gilbert wrote:
> You are one of four
> complicit in the act that finally pushed Joey over the edge [0].
Don't you think it goes a bit far to personally accusing some people of
this?
I guess Joey was long enough in the business to have known how to deal
wi
On Fri, 2014-11-07 at 17:04 -0400, Joey Hess wrote:
> but I'm out.
Wow what saddening news :-(
It's really a pity to good ones leaving... hope you'd reconsider your
decision and come back after some break perhaps!
If not, all the best and thanks.
Cheers,
Chris.
smime.p7s
Description: S/M
On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote:
> I would hope Debian never becomes a "truly security conscious"
> distribution by that definition.
> It implies the distribution thinks it
> knows better than its users what the right security trade-off is, and
> that way lies disaster.
I
On Thu, 2014-10-30 at 01:29 -0400, Michael Gilbert wrote:
> There is also LWN as a mechanism for independent verification.
Don't they just take up the information from Debian themselves?
> Although there is often more than a day long delay on that, and more
> on weekends
Which makes it inadequate
Hey again.
On Wed, 2014-10-29 at 22:07 -0700, Russ Allbery wrote:
> If you don't read the mail, you're going to miss some really vital
> information, like packages that we are no longer supporting. I am very
> much opposed to giving people the impression they can just monitor the
> security arch
Hey Russ.
On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
> Packages appearing on mirrors is not how we notify Debian users of
> security updates. We do that by issuing a security advisory.
Aha,... well... sounds like nitpicking,... I guess the least of the
users have subscribed the respe
Hey Henrique, et al.
I've had lost my interest a bit, since it feels like fighting
windmills... but one month has passed and it's perhaps a good time to
revisit this.
On Mon, 2014-09-29 at 08:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Sep 2014, Christoph Anton M
On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote:
> It feels to me like you're spending lots of time telling other people
> they're wrong and telling other people what they should be spending time
> on, and then arguing with anyone who tells you that how you're going about
> this isn't effect
On Wed, 2014-10-15 at 23:44 +, brian m. carlson wrote:
> HIGH:MEDIUM:!aNULL is a better default.
Still allows quite a number of combinations I probably wouldn't want to
entrust my data: RC4 stuff, DSS stuff, even some MD5 combination is in
the list.
smime.p7s
Description: S/MIME cryptograph
On Thu, 2014-10-16 at 10:55 +1100, Brian May wrote:
> What about security updates? Should Debian be releasing wheezy
> security updates for browsers, web servers, etc, that disable SSLv3
> by default now that SSLv3 is considered insecure?
I'd guess that as soon as the respective vendor issues a
On Wed, 2014-10-15 at 13:58 -0700, Russ Allbery wrote:
> The approach that you are taking to this discussion is destroying my
> desire and willingness to explain to you all of the nuance that you're
> ignoring.
Well I respect that you have another opinion on security, but I didn't
demand you to ex
On Wed, 2014-10-15 at 21:55 +0200, Jonas Meurer wrote:
> While I appreciate your efforts to raise security-relevant topics within
> the Debian distribution, I have to admit that exactly the same happens
> to quite a few of your "meta-bugreports" as well. There's a lot of
> discussion and a few cha
On Wed, 2014-10-15 at 15:18 -0400, Joey Hess wrote:
> I've talked about this with the git developers before, and while they
> seemed to have some ideas for how to handle a conversion to a different
> hash, they're not keen on doing it until forced by SHA1 being more
> broken than it is now.
Well,.
On Wed, 2014-10-15 at 20:25 +0100, Jonathan Dowland wrote:
> There are a number of mechanisms for proposing and tracking distro-wide
> changes, such as release goals and DEPs in some cases. But this is not what
> the
> general bug is for. Please choose something and then kindly close this bug.
We
Package: general
Severity: important
Tags: security
Hi.
Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:
---
To disable crypto algorithms and protocols per default, which are
known to be no longer secure, across Debian.
And ideally, to default to s
On Thu, 2014-09-25 at 21:56 +0200, Joerg Jaspert wrote:
> It also sounds quite stupid that suddenly all users have no working
> mirror anymore, should there be an outage of ftp-master or
> security-master longer than the signing time.
Well I don't see why this must necessarily happen.
Even if ftp-
On Fri, 2014-09-26 at 11:20 +0800, Paul Wise wrote:
> snapshot is a read-only (modulo cosmic rays and removal of
> non-redistributable things) historical record, files in it will not be
> modified to re-sign with newer keys nor to update Valid-Until.
So what would you do now, when one of the past
On Mon, 2014-09-15 at 00:04 +0200, Stefan Lippers-Hollmann wrote:
> Please consider that too short intervals (24h might still work, but
> it's hard on the limit) make non-primary (cron based) mirrors basically
> impossible. Including local mirrors used for systems that can't connect
> to the int
Hey Joerg.
On Sun, 2014-09-14 at 21:52 +0200, Joerg Jaspert wrote:
> Technically we could go down to 1 second, validtime is expressed in
> seconds in our setup.
;-)
> > My proposal would be something like that:
> > unstable/testing: 4-12 hours
> > [wheezy|squeeze]/updates at security.d.o: 1-6 h
Hey.
On Sat, 2014-09-06 at 14:08 +0200, Michael Biebl wrote:
> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
> going to make it the first alternative. Installing a half-broken logind
> whould be a disservice to our users.
Kinda strange to use *that* as an argument, while
Hey.
On 12/08/2014 18:30, Michael Niedermayer wrote:
> Also ive offered my resignation in the past. I do still offer to
> resign from the FFmpeg leader position, if it resolves this split
> between FFmpeg and Libav and make everyone work together again.
I have absolutely no opinion on the poli
On Wed, 2014-07-02 at 20:39 +0200, Svante Signell wrote:
> these packages. And, there won't be 50 000
> foo-must-die packages.
Packages are there to install software, not to prevent sucht
installation.
This is a perversion of any package management system.
What you want can be done via apt_prefe
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 Mon, 2014-06-23 at 08:58 +1000, Russell Stuart wrote:
> > Well first, AFAIK, there are no mirrors for the BTS... and then
> > securing something like BTS with OpenPGP is quite difficult.
> There is a straight forward solution to handling BTS messages. You just
> DKIM sign them with an appropri
On Sun, 2014-06-22 at 14:21 +1000, Russell Stuart wrote:
> Sure, but you are no longer discussing a PKI system here. If you are
> going to abandon X.509 PKI
Well first of all,... PKI is just "public key infrastructure" and not
necessarily means X.509.
> , why not just use OpenPGP and just have
>
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
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 Sun, 2014-06-22 at 10:52 +1000, Russell Stuart wrote:
> The problem isn't that government security agencies can in all
> likelihood MITM any connection they wish. I'm sure that's true, but I'm
> equally sure they don't do it that often for fear of being caught. It's
> actually far worse than
On Sat, 2014-06-21 at 16:40 +0200, Tollef Fog Heen wrote:
> That user trusts us to build a distro fairly competently, something we
> have a history of doing.
Well it's not that we'd have never made mistakes there...
> That user would then trust us to run a CA competently, something we as a
> pro
On Sat, 2014-06-21 at 03:41 +0200, Matthias Urlichs wrote:
> Christoph Anton Mitterer:
> > In OpenPGP you have the additional problems that:
> > - at least until know communication with the keyservers is usually
> > unsecured: so not only the keyserver operator can attack you
On Wed, 2014-06-18 at 10:05 -0700, Russ Allbery wrote:
> This is only true if the root CA is maintained with the same level of
> security as the PGP signing key for the archive.
Well and currently, people trust GANDI when they download (then possibly
forged) Debian images?
Actually even less, sinc
On Wed, 2014-06-18 at 15:29 +0200, Vincent Lefevre wrote:
> At least you
> need some 3rd party to check certificate revocation. But if it is
> malicious, it could tell you that the certificate has been revoked
> (even if it isn't), and you have the same problem as now... well,
> almost.
It's actu
On Wed, 2014-06-18 at 14:20 +1000, Russell Stuart wrote:
> Precisely. It has a horrible design bug.
>
> Given the nature of the net, where we want to deal securely with some
> entity never dealt with or of heard of before like, www.shop.com, we
> are forced to rely on a third party to assure us
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
On Tue, 2014-06-17 at 21:00 +0200, Kurt Roeckx wrote:
> This should be supported by all libraries, and is being used.
> More and more intermediate CAs are in the process of becomming
> constrained.
Which doesn't really help, if you have still >150 "root" CA certs in
Mozilla... which can just do wh
On Tue, 2014-06-17 at 13:20 +0100, Simon McVittie wrote:
> * my browser vendor doesn't trust this CA at all, and indeed my browser
> will not let me access https sites secured with it, even though it
> will let me access an equally MITM-prone http version of the same
> content
>
> * my bro
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 18:25 +, Luca Filipozzi wrote:
> But I don't expect that to be anywhere close to sufficient for other distros
> to
> include the Debian CA (by which you probably mean the SPI CA) into their
> certificate stores.
I didn't mean their Mozilla/NSS cert stores, if you were ta
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
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.
On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote:
> > Supplying the Debian Root CA to people not using Debian could have been
> > easily done by a *single* site that uses a cert available in all
> > browsers... which offers the Debian Root CA for secure and "trusted"
> > download.
>
> Tha
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, 2014-06-12 at 10:56 +0200, Jakub Wilk wrote:
> $ grep -r /soap.cgi lib/
> lib/debian/btssoap.rb:
> @server="http://#{host}:#{port}/cgi-bin/soap.cgi";
:-(
> bts(1) and reportbug(1) don't use HTTPS either, AFAICS.
:-(
> I noticed that http://bugs.debian.org/ started redirecting to
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 under
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
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
reopen 749795
stop
Hi.
I'm reopening this for now, even if the issue is solved from a technical
point of view (see below why).
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.
On Fri, 2014-02-14 at 19:15 +0100, Matthias Urlichs wrote:
> http://www.markshuttleworth.com/archives/1316
That's really interesting... and disturbing... in so many ways.
First, while I don't like everything about systemd, I was/am in favour
of it (as long as we can keep the non-Linux ports alive
On Mon, 2013-10-28 at 19:23 +, Mirosław Baran wrote:
> And the RH PR circus has already started around it.
> Lennart's g+ note is written in his usual half-truth/half-omission mode. Not
> helpful at all.
I guess just stating something like this, without real technical
arguments why he is wrong
1 - 100 of 351 matches
Mail list logo
