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 ar
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 res
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
Joey Hess 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 servers prob
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, 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
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 woul
Christoph Anton Mitterer 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 with anyone who te
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 16 October 2014 10:44, brian m. carlson
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]
> should have to disable expor
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
> security-hard
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 che
Christoph Anton Mitterer 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 based on compati
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, 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 do
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 b
Joey Hess 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 servers pro
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
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
wi
21 matches
Mail list logo
