Joey Hess jo...@debian.org writes:
In general, I think that Debian needs to identify upstreams that are
being proactive about dropping old crypto algos, and those that are not.
Major browsers, openssh upstream, etc are going to be more on top of
this than we are, and make better decisions. Web
On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
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
On Wed, 15 Oct 2014, Christoph Anton Mitterer wrote:
I see it a bit differently:
RC4 is broken. Full stop.
Therefore new versions clients and servers should per default not
use/enable/accept it.
Sorry, but I *have* to nitpick here.
RC4 as used by SSL is mostly broken. (A server could reset
Lars Wirzenius writes (Re: Bug#765512: general: distrust old crypto algos and
protocols perdefault):
Merely defending one's opinions is a recipe for long threads. A good,
productive discussion about Debian development requires understanding
other people's arguments, evaluating one's own point
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
Christoph Anton Mitterer wrote:
For git it's e.g. quite clear that it's use of SHA1 *is* security
relevant.
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
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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
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,...
Joey Hess jo...@debian.org writes:
In general, I think that Debian needs to identify upstreams that are
being proactive about dropping old crypto algos, and those that are not.
Major browsers, openssh upstream, etc are going to be more on top of
this than we are, and make better decisions.
Hey,
Am 15.10.2014 um 21:44 schrieb Christoph Anton Mitterer:
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
On Wed, Oct 15, 2014 at 09:44:43PM +0200, Christoph Anton Mitterer wrote:
Well a bug is at least something, where one has a central log of all
discussions... and where one can really keep track of...
Only if people remember to copy it. And that's less likely to happen
when you start getting
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
Christoph Anton Mitterer cales...@scientia.net writes:
On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:
For another example, upstream for both Heimdal and MIT Kerberos know
very well what the situation is with the RC4 use in the Kerberos
protocol and are making well-informed decisions
* Christoph Anton Mitterer:
Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:
Fedora is currently working on this:
https://fedoraproject.org/wiki/Changes/CryptoPolicy
However, it is an ongoing effort to make applications adhere to the
system
Joey Hess writes (Bug#765512: general: distrust old crypto algos and protocols
perdefault):
Instead, it makes sense to adapt workflows that do not trust git hashes,
which mostly means making signed tags and commits, and checking the
signatures. This is something Debian could improve in many
On Wed, Oct 15, 2014 at 11:47:07PM +0100, Ian Jackson wrote:
Joey Hess writes (Bug#765512: general: distrust old crypto algos and
protocols perdefault):
Instead, it makes sense to adapt workflows that do not trust git hashes,
which mostly means making signed tags and commits, and checking
On Wed, Oct 15, 2014 at 01:58:34PM -0700, Russ Allbery wrote:
It's unlikely that you're going to be able to make better cost/benefit
decisions about these things than well-informed upstreams for general use
cases. Debian is targeted for general use cases. If we were making a
On 16 October 2014 10:44, brian m. carlson sand...@crustytoothpaste.net
wrote:
Unfortunately, not all upstreams make good decisions. OpenSSL ships
with a set of default ciphers that is completely insecure. There is no
reason that every application using OpenSSL directly or indirectly[0]
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
Christoph Anton Mitterer cales...@scientia.net writes:
So what's wrong about my approach, apart from the paradigm security
first?
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
Christoph Anton Mitterer writes (Re: Bug#765512: general: distrust old crypto
algos and protocols perdefault):
So what's wrong about my approach, apart from the paradigm security
first?
Firstly, I agree with everything Russ has said.
But secondly, I would worry that you're perhaps not paying
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 Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
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
26 matches
Mail list logo
