On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
> Additionally, since debian.org uses DNSSEC, if you can somehow MITM
> people.debian.org then due to DANE you can MITM it for HTTP as well as
> HTTPS, so forcing HTTPS really doesn't gain you much.
But that implies that the attacker has acces
Package: wnpp
Severity: wishlist
Owner: LIU Dongyuan
* Package name: fonts-adobe-sourcehansans-cn
Version : 1.000
Upstream Author : Ken Lunde
* URL : http://sourceforge.net/projects/source-han-sans.adobe/
* License : Apache 2.0
Description : “Source Han
Package: wnpp
Severity: wishlist
Owner: LIU Dongyuan
* Package name: fonts-adobe-sourcehansans-jp
Version : 1.000
Upstream Author : Ken Lunde
* URL : http://sourceforge.net/projects/source-han-sans.adobe/
* License : Apache 2.0
Description : “Source Han
Package: wnpp
Severity: wishlist
Owner: LIU Dongyuan
* Package name: fonts-adobe-sourcehansans-twhk
Version : 1.000
Upstream Author : Ken Lunde
* URL : http://sourceforge.net/projects/source-han-sans.adobe/
* License : Apache 2.0
Description : “Source Ha
Package: wnpp
Severity: wishlist
Owner: LIU Dongyuan
* Package name: fonts-adobe-sourcehansans-kr
Version : 1.000
Upstream Author : Ken Lunde
* URL : http://sourceforge.net/projects/source-han-sans.adobe/
* License : Apache 2.0
Description : “Source Han
Hi,
Ondřej Surý:
> Pervasive monitoring.
In and of itself, if you only access publicly-availble files, that's not a
threat.
> Really we should introduce encryption
> *everywhere*.
>
This change does not introduce encryption.
It disables the option not to use encryption.
I can accept that e.g.
Op zondag 20 juli 2014 09:23:55 schreef u:
> On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
> > Additionally, since debian.org uses DNSSEC, if you can somehow MITM
> > people.debian.org then due to DANE you can MITM it for HTTP as well as
> > HTTPS, so forcing HTTPS really doesn't gain you
Hi All,
On Sat, 2014-07-19 at 22:57 +0300, Arto Jantunen wrote:
> (please don't CC me on replies, I read the list)
>
> Abou Al Montacir writes:
> >> We have several forums for user support requests, the main one being
> >> debian-user@l.d.o. The bts "general" pseudopackage is not a user support
Op zondag 20 juli 2014 08:47:07 schreef Tollef Fog Heen:
> ]] Wouter Verhelst
>
> > Op zaterdag 19 juli 2014 22:54:47 schreef u:
> > > ]] Wouter Verhelst
> > >
> > > > Op zondag 13 juli 2014 22:13:10 schreef Martin Zobel-Helas:
> > > > > Furthermore, we will change the people.debian.org web-servi
On Sun, 2014-07-20 at 07:50 +0800, Paul Wise wrote:
> On Sun, Jul 20, 2014 at 2:56 AM, Abou Al Montacir wrote:
>
> > I'd recommend that reportbug(-ng) provide a clear message when creating
> > a bug, just like some other packages do it (evolution to name my
> > preferred mail client). This will th
On Sun, 2014-07-20 at 11:09 +0200, Abou Al Montacir wrote:
> > Please file bugs about it. Unfortunately reportbug{,-ng} maintenance
> > is not happening often right now so it might take a long time for
> that
> > to happen.
> Sure I'll do.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755392
On Sun, Jul 20, 2014 at 09:23:55AM +0200, Ondřej Surý wrote:
> On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
> > > There are lots of attack vectors. It's not a response to a single
> > > attack being exploited in the wild.
> > So name one?
> Pervasive monitoring. Really we should introd
* Tollef Fog Heen , 2014-07-20, 08:47:
Would you be happy with
http://people.debian.org/THIS-IS-INSECURE/YES-I-WANT-TO-PROCEED/~user/file
as the URLs?
No need to be condescending. :-(
Also, I wouldn't say “insecure”, which might be vague in this context.
My proposal:
http://nohttps.people.d
On 20 July 2014 10:07, Wouter Verhelst wrote:
> With the state of the CA cartel these days, I have little
> trust in the strength of HTTPS as a verification mechanism, and so I
> wouldn't trust a file to be correct even if it came through an HTTPS
> connection that validates. Instead, I would only
On Sun, 20 Jul 2014 10:45:10 +0200, Wouter Verhelst wrote:
>Op zondag 20 juli 2014 09:23:55 schreef u:
>> On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
>> > Additionally, since debian.org uses DNSSEC, if you can somehow MITM
>> > people.debian.org then due to DANE you can MITM it for HTTP
On Sun, 20 Jul 2014, Steve Langasek wrote:
> On Sun, Jul 20, 2014 at 09:23:55AM +0200, Ondřej Surý wrote:
> > On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
> > > > There are lots of attack vectors. It's not a response to a single
> > > > attack being exploited in the wild.
>
> > > So na
On 07/19/2014 08:49 PM, Abou Al Montacir wrote:
Control: reopen -1
On Sat, 2014-07-19 at 17:03 +, Debian Bug Tracking System wrote:
...
Missing information, dupe.
Kind regards,
Andrei
Hi Andrei,
I don't think that missing information is enough argument to close a
bug.
Hi AL Nik,
Can y
On Sun, 20 Jul 2014, Ondřej Surý wrote:
> Pervasive monitoring. Really we should introduce encryption
> *everywhere*.
And indeed we have been moving towards https for most services over the
last 12 months.
www is still not done, due to unfortunate push-bash by the service
owners, but most others
On Sun, Jul 20, 2014 at 07:50:17AM +0800, Paul Wise wrote:
> I think that would probably just add more noise to debian-devel.
Maybe "general" bugs should go to debian-user instead?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac
At Sun, 20 Jul 2014 11:07:16 +0200,
Wouter Verhelst wrote:
> Even ignoring that, assuming people trust that code off
> people.debian.org is "safe", if they run a validating DNS resolver they
> don't run more of a risk than if they use only HTTPS.
I don't really follow that. A validating DNS resolv
Op zondag 20 juli 2014 11:06:00 schreef Tim Retout:
> On 20 July 2014 10:07, Wouter Verhelst wrote:
> > With the state of the CA cartel these days, I have little
> > trust in the strength of HTTPS as a verification mechanism, and so I
> > wouldn't trust a file to be correct even if it came through
Op zondag 20 juli 2014 12:53:59 schreef Jeroen Dekkers:
> At Sun, 20 Jul 2014 11:07:16 +0200,
>
> Wouter Verhelst wrote:
> > Even ignoring that, assuming people trust that code off
> > people.debian.org is "safe", if they run a validating DNS resolver they
> > don't run more of a risk than if they
On Sun, July 20, 2014 08:15, Wouter Verhelst wrote:
> Op zaterdag 19 juli 2014 22:54:47 schreef u:
>> > Please note that there remain cases where accessing HTTPS is difficult
>> > or impossible. One of these (but by no means the only one) is the
>> > current release of debian-installer: the wget im
Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
> On Sun, 20 Jul 2014 10:45:10 +0200, Wouter Verhelst wrote:
> >Op zondag 20 juli 2014 09:23:55 schreef u:
> >> On Sun, Jul 20, 2014, at 08:15, Wouter Verhelst wrote:
> >> > Additionally, since debian.org uses DNSSEC, if you can somehow MITM
> >>
On Sun, 20 Jul 2014 13:21:03 +0200, Wouter Verhelst wrote:
>Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
>> I might me missing something, and I admit not having read the entire
>> thread, but how would they have access to private key material?
>
>Beyond GPG keys there are also DNSSEC privat
]] Wouter Verhelst
> AFAIK, people.debian.org does not allow running server-side HTTP scripts
> (and even if it does, I think that's a bad idea and we should disable it
> ASAP). As such, people.debian.org is not an interface for reading mail
> in your browser over HTTP, or doing IRC, or whatnot.
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> These are all good arguments for enabling HTTPS and making it the
> default (which I've said repeatedly is a move that I support, or at the
> very least don't oppose), but not for *disabling* the possibility of
> plain HTTP.
Pray tell: How do you make
On Sun, Jul 20, 2014 at 10:38:23AM +0200, Matthias Urlichs wrote:
> > Pervasive monitoring.
>
> In and of itself, if you only access publicly-availble files, that's not a
> threat.
1 Security service has unknown exploit.
2 Pervasive monitoring sees you install a package from somewhere over HTTP.
On Sun, Jul 20, 2014 at 12:03:59PM +0200, Jakub Wilk wrote:
> My proposal:
> http://nohttps.people.debian.org/~user/file
This is similar to my proposal[1], using a seperate VHOST that would allow HTTP
access. It's clear in the URL what is going on, and most people will be
using HTTPS but there are
On Sun, Jul 20, 2014 at 01:52:20PM +0200, Peter Palfrader wrote:
> On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> > These are all good arguments for enabling HTTPS and making it the
> > default (which I've said repeatedly is a move that I support, or at the
> > very least don't oppose), but not for
On Sun, 20 Jul 2014, Iain R. Learmonth wrote:
> > Pray tell: How do you make it default.
>
> See: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
>
> It sends a header to tell you you should be using HTTPS.
Alas, that's not what HSTS is about or for. It cannot be used for this.
-
On Sat, Jul 19, 2014 at 08:25:05PM +0200, Abou Al Montacir wrote:
> because it is duplicate and not because it is missing information. It
> may be clear for may that "dupe" means duplicate, but this is not clear
> for every body especially that in French this means "stupid".
Considering the langu
On Sun, 2014-07-20 at 13:10 +0300, Aleksandar Nikolov wrote:
> I tried this experiment:
> Installed sshd and connected from another computer - it works. But
> after
> the lid closed and opened, I cannot connect. The system must be dead,
> although the fans blows and the power led is on.
This mean
hello
searching on packages.debian.org shows btrfs only for testing, oldstable,
NOT in stable? how that?!
please also CC me (not in mailinglist)
thanks
Andrew
Not a user of btrfs, but the userspace tools are in package btrfs-tools
https://packages.debian.org/search?keywords=btrfs-tools
and the kernel modules seem to be in the default kernel packages
$ dpkg -L linux-image-3.2.0-4-amd64 | grep btrfs.ko
/lib/modules/3.2.0-4-amd64/kernel/fs/btrfs/btrfs.ko
W dniu 20/07/2014 11:01, Peter Palfrader napisał(a):
I do think that if DSA are going to enforce such a policy, they should
be
able to explain why.
"What Ondřej said"
a.k.a. “because”. Do try better.
– j.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject o
On Sun, Jul 20, 2014 at 10:55:55AM +0200, Abou Al Montacir wrote:
> upgrade ==> not working anymore ==> bug
> I think this is a typical acceptable situation, what ever the user's
> level of experience.
> It is more about how much we care about our users rather than about the
> validity of the bug r
Op zondag 20 juli 2014 13:52:20 schreef Peter Palfrader:
> On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> > These are all good arguments for enabling HTTPS and making it the
> > default (which I've said repeatedly is a move that I support, or at the
> > very least don't oppose), but not for *disabli
Op zondag 20 juli 2014 13:28:43 schreef Marc Haber:
> On Sun, 20 Jul 2014 13:21:03 +0200, Wouter Verhelst wrote:
> >Op zondag 20 juli 2014 11:38:13 schreef Marc Haber:
> >> I might me missing something, and I admit not having read the entire
> >> thread, but how would they have access to private k
On Sun, Jul 20, 2014, at 12:06, Tim Retout wrote:
> On 20 July 2014 10:07, Wouter Verhelst wrote:
> > With the state of the CA cartel these days, I have little
> > trust in the strength of HTTPS as a verification mechanism, and so I
> > wouldn't trust a file to be correct even if it came through a
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> > > These are all good arguments for enabling HTTPS and making it the
> > > default (which I've said repeatedly is a move that I support, or at the
> > > very least don't oppose), but not for *disabling* the possibility of
> > > plain HTTP.
> >
> > Pr
On Sun, Jul 20, 2014 at 06:19:14PM +0200, Peter Palfrader wrote:
> None of these brings people who type in people.debian.org into their
> browser to https.
Right.
AFAICT the only technical change that will do that (sanely) is an
HTTP-level redirection from http://(.*) to https://$1 . Having that
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-javascript-de...@lists.alioth.debian.org, debian-p...@lists.debian.org
* Package name: prettify
Version : 2013.03.04
Upstream Author : mikesam...@gmail.com
* URL
On 2014-07-20 08:15, Wouter Verhelst wrote:
True, but debian-installer simply does not support any signed/encrypted
preseeding.
[…]
Granted, these are probably bugs, and IIRC Colin was working on
providing HTTPS support for jessie. Still, I while I support enabling
HTTPS for people.d.o, I think
On Sun, Jul 20, 2014 at 08:23:58PM +0200, Philipp Kern wrote:
> On 2014-07-20 08:15, Wouter Verhelst wrote:
> >True, but debian-installer simply does not support any signed/encrypted
> >preseeding.
> […]
> >Granted, these are probably bugs, and IIRC Colin was working on
> >providing HTTPS support f
Op zondag 20 juli 2014 18:19:14 schreef Peter Palfrader:
> On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> > > > These are all good arguments for enabling HTTPS and making it the
> > > > default (which I've said repeatedly is a move that I support, or at
> > > > the
> > > > very least don't oppose),
On Sun, 20 Jul 2014, Stefano Zacchiroli wrote:
> AFAICT the only technical change that will do that (sanely) is an
> HTTP-level redirection from http://(.*) to https://$1 .
That is my understanding as well.
> - it's not entirely clear how much extra work implementing this would
> require. In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/20/2014 03:08 PM, Wouter Verhelst wrote:
> Op zondag 20 juli 2014 18:19:14 schreef Peter Palfrader:
>> None of these brings people who type in people.debian.org into
>> their browser to https.
>
> If they type it in because they want to avoi
On Sun, 20 Jul 2014, Wouter Verhelst wrote:
> If HSTS is enabled and you access people.debian.org even once (and you
> don't clear out their entire cache for as long as the HSTS timeout
> lives), then HSTS will ensure that the HTTP URL gets turned into an
> HTTPS URL automatically.
Alas, no.
--
On Sun, Jul 20, 2014 at 01:19:58PM +0200, Thijs Kinkhorst wrote:
> On Sun, July 20, 2014 08:15, Wouter Verhelst wrote:
> > Op zaterdag 19 juli 2014 22:54:47 schreef u:
> >> > Please note that there remain cases where accessing HTTPS is difficult
> >> > or impossible. One of these (but by no means t
On 07/20/2014 04:25 PM, Abou Al Montacir wrote:
On Sun, 2014-07-20 at 13:10 +0300, Aleksandar Nikolov wrote:
I tried this experiment:
Installed sshd and connected from another computer - it works. But
after
the lid closed and opened, I cannot connect. The system must be dead,
although the fans
On Sun, Jul 20, 2014 at 09:00:05PM +0200, Peter Palfrader wrote:
> IMO, a dedicated vhost name sounds much more appealing than magic apache
> configs. I wonder whether it should use the same UserDirs.
Oh, right. With different UserDirs (bonus point: the default one,
public_html/, being the one t
On Mon, Jul 21, 2014 at 12:05:56AM +0200, Stefano Zacchiroli wrote:
> On Sun, Jul 20, 2014 at 09:00:05PM +0200, Peter Palfrader wrote:
> > IMO, a dedicated vhost name sounds much more appealing than magic apache
> > configs. I wonder whether it should use the same UserDirs.
>
> Oh, right. With d
Hi,
On Sun, Jul 20, 2014 at 07:30:35PM +0100, Colin Watson wrote:
> I'll hopefully get to finishing this at DebConf; I think I merged most
> of the safe and independent pieces already, and mostly just need to deal
> with wget-udeb. I'm not expecting to backport this to wheezy though.
yeah, it se
On Sun, Jul 20, 2014 at 9:12 PM, Chris Bannister wrote:
> Considering the language is English, it would be a pity if the reader
> made this mistake. Let's assume a modicum of 'common sense' at least.
With an international project like Debian, we can't assume that
English is everyone's first langu
On Sun, Jul 20, 2014 at 3:59 PM, LIU Dongyuan wrote:
> * Package name: fonts-adobe-sourcehansans-cn
Due to the need for Adobe's ADFKO, this will have to go to contrib.
IIRC ADFKO will become open source at some point and the font could
move to main then.
--
bye,
pabs
https://wiki.debian.or
On Sun, Jul 20, 2014 at 4:13 PM, LIU Dongyuan wrote:
> * Package name: fonts-adobe-sourcehansans-jp
Due to the need for Adobe's ADFKO, this will have to go to contrib.
IIRC ADFKO will become open source at some point and the font could
move to main then.
--
bye,
pabs
https://wiki.debian.or
On Sun, Jul 20, 2014 at 4:16 PM, LIU Dongyuan wrote:
> * Package name: fonts-adobe-sourcehansans-kr
Due to the need for Adobe's ADFKO, this will have to go to contrib.
IIRC ADFKO will become open source at some point and the font could
move to main then.
--
bye,
pabs
https://wiki.debian.o
Hi
On Mon, 21 Jul 2014, Paul Wise wrote:
> Due to the need for Adobe's ADFKO, this will have to go to contrib.
> IIRC ADFKO will become open source at some point and the font could
> move to main then.
Why? There are many fonts around in otf format and packaged for
Debian. I don't see that proble
On Mon, 21 Jul 2014, Norbert Preining wrote:
> On Mon, 21 Jul 2014, Paul Wise wrote:
> > Due to the need for Adobe's ADFKO, this will have to go to contrib.
> > IIRC ADFKO will become open source at some point and the font could
> > move to main then.
>
> Why? There are many fonts around in otf fo
On Sun, Jul 20, 2014 at 6:29 PM, Jonathan Dowland wrote:
> On Sun, Jul 20, 2014 at 07:50:17AM +0800, Paul Wise wrote:
>> I think that would probably just add more noise to debian-devel.
>
> Maybe "general" bugs should go to debian-user instead?
That would be change in meaning of the pseudo-package
On 07/21/2014 12:19 AM, Peter Palfrader wrote:
> On Sun, 20 Jul 2014, Wouter Verhelst wrote:
>
These are all good arguments for enabling HTTPS and making it the
default (which I've said repeatedly is a move that I support, or at the
very least don't oppose), but not for *disabling*
62 matches
Mail list logo
