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
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
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
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)
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
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.
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/
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
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
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.
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,
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
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
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
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
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
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: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, and
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 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 script
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 asked
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)
Maybe,
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 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 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 NetworkManager
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
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 could
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...)
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
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
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
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 optional
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 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
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
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,
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 it into
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 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,
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 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
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 the
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:
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 archive
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
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.
Isn't
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 Mitterer wrote
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
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
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.
Well
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 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 changes
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
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 an
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
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
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 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
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 hours
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
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
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
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 appropriate
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
squeeze: no
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 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 me
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 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
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
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 soon
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
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 system
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 shell,
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. Nowadays
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
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 the
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 actually
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, since
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, but anyone
else that can
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 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
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
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 browser
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
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 the
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.
That's a nice
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 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
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
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 build
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, 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 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 the
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
For those who haven't seen it, Lennart has posted some of his comments
about all this on G+:
https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
1 - 100 of 351 matches
Mail list logo
