Re: people.debian.org redirecting browsers to HTTPS (was: people.debian.org will move from ravel to paradis and become HTTPS only)

2014-07-20 Thread Thomas Goirand
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* the possibility of
 plain HTTP.
>>>
>>> Pray tell: How do you make it default.
>>
>> - Enable HSTS on the domain
>> - Run "sed -i -e 's,http://people.debian.org,https://people.debian.org,g'"
>>   over a webwml export.
>> - Create a robots.txt file which is visible from the HTTP export (but
>>   not from the HTTPS one) which looks like this:
> 
> None of these brings people who type in people.debian.org into their
> browser to https.

This could be achieve with mod_rewrite and parsing the user agent:

RewriteEngine  on
RewriteCond %{HTTP_USER_AGENT}  ^SomeBrowser/(.*)$
RewriteRule ^(.*)$ https://test.domain.com/$1 [L,R=302]

This could be implemented in the vhost directive, and makes HTTPS
mandatory for the user agent SomeBrowser, the HTTP being effectively not
reachable for it.

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ccb2bb.6050...@debian.org



Re: How Debian should handle users requests?

2014-07-20 Thread Paul Wise
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, it isn't
supposed to be for user support. Personally I don't think that we need
the general/base/cdrom/project pseudo-packages any more. At minimum we
should update reportbug to discourage their use.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6H2Mtt62az_pNjQ0QD7dT8-8cCGxB8+rSC4O=z+xmr...@mail.gmail.com



Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

2014-07-20 Thread Norbert Preining
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 format and packaged for
> Debian. I don't see that problem here.
> 
> Is the ADFKO needed for building? We never *build* a otf font but
> ship it.

Addition - these fonts are distributed in OTF format. So no building.
Are you talking about embedded code snippets like for the hinting code?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721002449.gs6...@auth.logic.tuwien.ac.at



Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

2014-07-20 Thread Norbert Preining
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 problem here.

Is the ADFKO needed for building? We never *build* a otf font but
ship it.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721002254.gr6...@auth.logic.tuwien.ac.at



Re: Bug#755386: ITP: fonts-adobe-sourcehansans-kr -- “Source Han Sans KR” A sans-serif Pan-CJK font family (KR subset) that is offered in seven weights

2014-07-20 Thread Paul Wise
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.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Gzxjk2Gm7=_uecxwgxeovwmvps-d9se4y5hek17pi...@mail.gmail.com



Re: Bug#755385: ITP: fonts-adobe-sourcehansans-jp -- “Source Han Sans JP” A sans-serif Pan-CJK font family (JP subset) that is offered in seven weights

2014-07-20 Thread Paul Wise
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.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hnzavovm4p0-seip1naeluqlmswpursmxtstqsfkb...@mail.gmail.com



Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

2014-07-20 Thread Paul Wise
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.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gmf2x1o2u-nks04rvfrx7quc4fl66doeqihzpmkhc...@mail.gmail.com



Re: Bug#755285: marked as done (general: Black screen on resume after suspend)

2014-07-20 Thread Paul Wise
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 language. As a result it would be 'common
sense' to use clear English and avoid possibly ambiguous words. Also,
'dupe' in English has a similar dictionary meaning as French.

http://dictionary.reference.com/browse/dupe

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6ebd8ydhsa3uae9ux8v9n0eublupuxjvzxjjgxzud5...@mail.gmail.com



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Philipp Kern
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 seems that you merged everything into git already. Yay!

It's wget-udeb (relatively easy), but it's also either a new udeb for gnutls or
like in Ubuntu one for libssl. (You sure know, but for the benefit of the
list.)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Luca Filipozzi
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 different UserDirs (bonus point: the default one,
> public_html/, being the one that works https-only) people can simply use
> symlinks.

I'm in favour of soylent.debian.org since soylent [green] is people.

*cough*

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720222052.ga23...@emyr.net



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Stefano Zacchiroli
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 that works https-only) people can simply use
symlinks.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature


Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)

2014-07-20 Thread Aleksandar Nikolov


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 blows and the power led is on.

This means that your system hanged either during going into sleep mode
or when exiting the sleep mode. This is then not a screen issue but a
system issue. The fact that fans are on may indicate that the issue
happened when exiting suspend mode. But we definitely need more
information.

Further after restart I found that nothing was written in neither
dmesg

dmesg does not remember messages from old boot, you need to relay on
logs

nor pm-powersave.log after the lid is closed and then opened.

yes this is normal as you rebooted. Then this file will be filled for
the next time but you won't be able to recover it. Normally you should
find a /var/log/pm-*.log.1, these files are the ones you need to
provide.
I marked both dmesg and pm-powersave.log by adding a specific line at 
the bottom and I am pretty sure that nothing is appended to them or to 
the renamed ones after lid closed and lid opened. Of course after 
restart the old files was renamed but my marks was still at the bottom 
of the old files.


Also it could be better if you try using the official Debian kernel, at
least while we are investigating the issue. I assume you have good
reason to use an other kernel, but we do not support such combinations,
so please ensure investigating this bug with:
(jessie)root@karim:~# aptitude show linux-image-amd64
Package: linux-image-amd64
State: not installed
Version: 3.14+58
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team 
Architecture: i386
Uncompressed Size: 38.9 k
Depends: linux-image-3.14-1-amd64
Provides: linux-latest-modules-3.14-1-amd64
Description: Linux for 64-bit PCs (meta-package)
  This package depends on the latest Linux kernel and modules for use on
PCs with AMD64, Intel 64 or VIA Nano processors.
  
  This kernel also runs on a Xen hypervisor.  It supports both privileged

(dom0) and unprivileged (domU) operation.
I DO prefer using standard official kernel, but 3.14 doesn't support my 
video card - shows a black screen after grub. Thats why I installed 3.15 
and 3.16.


And all the thing had worked well till update at 07.07.


Cheers,
Abou Al Montacir

Best regards,
Aleksandar


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/12037543.3801405885314689.JavaMail.jmail@sarge



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Peter Palfrader
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.
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720192247.gq...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Steve Langasek
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 the only one) is the
> >> > current release of debian-installer: the wget implementation inside
> >> > stable d-i does not support https, so downloading files from
> >> > people.d.o (e.g., for preseeding) will become impossible if this is
> >> > implemented as stated.

> >> Hopefully you're not preseeding from a HTTP source, since that means
> >> you're quite vulnerable to trivial MITM attacks

> > True, but debian-installer simply does not support any signed/encrypted
> > preseeding.

> If you insist on using http, you can also just host your preseed files on
> http://grep.be. I don't see why DSA should wait to implement improvements
> to Debian services while there are perfect alternatives available to suit
> your use case.

Because it's not an improvement to the service; it's a change that makes the
*service* to Debian developers worse, for political reasons.

Telling DDs "you can just host the files on your own server" is missing the
point of why people.debian.org exists in the first place.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread The Wanderer
-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 avoid HTTPS for whatever
> local reason, then that's a feature, not a bug.
> 
> If they type it in because they were given a HTTP URL rather than a
> HTTPS one by someone else, then you should cluebat that someone else.

What if they don't type in any protocol, but just type in the server
name? That's very common among people who are less technically inclined
(and who bother to type URLs at all), and even among those who are more
so, ever since the day browsers first implemented the necessary smarts
to let it work in the first place.

Most browsers, and for that matter other HTTP clients, will default to
trying HTTP - not HTTPS - if given a URL that doesn't specify any
protocol. I'm anal-retentive about typing the full URL (including
protocol) manually when not just clicking on a link, as a matter of
standing on principle, and even I just accept that default sometimes.

Changing that default, without forcing HTTPS in the way which people in
this thread are objecting to, would seem to require changing all of
those clients - a much, much bigger proposition than the administrators
of any one server can practically tackle.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTzBZIAAoJEASpNY00KDJrlvkP/AytcRxckyGfR1qRu92Tto9F
fkQKeUisziYe2/hTwlhXAwBp5wSZryXBJWMyyQSgwxm31EXvLrKg8DWlVc0l+CKm
GSE1sFW1RjB8iaSZ7Joy0M+nu2rS7W+NMlTPIbeJ8QzGBqYb+QyhTHchJyIw1NmR
j+1HsUWJwU69xEOvsk3Goev3OYe6xGGVwOqjYj2f3x7O2C063qi8YhvvsL6oXqgC
2JBZWsXLUDtfrHUZ4c2agkv6hjxZqIuWZkydcsRmHlUKqO9yqOjgMSr6bWNhjqlz
ASpvuFpmA63xhqQ3NOVgoGQrwrPft/Lx6JGbgLmu/KSBPfH5GEzLipsJJjBtUo9+
122kjba+gEXy+CNHU4Fny9+ZuxlMNqsDyeDqVDLMP76PdlWOw3F2ramYhgiPHsHm
NyRNva8aQbsoH0B9Z9RsdbD3TbtNjL7fDerZ3dQEnPuwR9Xt451V/ATk77TuaSpI
IIOvNRZDSG3fX6KZ41g/GyvJHyjaJ8r+5sUcbco042btymbCKjxTHEyWjB1f8ZGj
GTndBcbgXn2hMKA/qMIDk+V+HJC+gdm4nx0h/ARRS856V9Fx7YQbSNz334q3ctqY
MjIdIzNLkJif1g6FNdEhAhPYl5F7j4aywHEcwh9FQbt4pGXzuwa7fDTrznmCs0gT
gPn4CIcCyRjzNrUWhSC9
=JiyN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53cc1648.10...@fastmail.fm



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Peter Palfrader
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 particular, I haven't put much thought in an easy way to
>   implement the directory-level opt-out.
> 
> - I *personally* don't mind having https only, quite the contrary! But I
>   got hooked by the discussions and couldn't resist proposing an API :)
>   (sorry)

IMO, a dedicated vhost name sounds much more appealing than magic apache
configs.  I wonder whether it should use the same UserDirs.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720190005.gp...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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), but not for *disabling* the possibility of
> > > > plain HTTP.
> > > 
> > > Pray tell: How do you make it default.
> > 
> > - Enable HSTS on the domain
> > - Run "sed -i -e 's,http://people.debian.org,https://people.debian.org,g'"
> > 
> >   over a webwml export.
> > 
> > - Create a robots.txt file which is visible from the HTTP export (but
> > 
> >   not from the HTTPS one) which looks like this:
> 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 avoid HTTPS for whatever local
reason, then that's a feature, not a bug.

If they type it in because they were given a HTTP URL rather than a
HTTPS one by someone else, then you should cluebat that someone else.

Write a bot for IRC that cluebats people automatically if they provide
HTTP rather than HTTPS URLs, for instance. Complain on mailinglists if
you want to.

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.

What's the problem? Unencrypted traffic is *not* evil. Neither are
people who for whatever local reason need to disable HTTPS.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3393543.bd2t4uq...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Colin Watson
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 for jessie. Still, I while I support enabling
> >HTTPS for people.d.o, I think disabling HTTP is overdoing it.
> 
> FWIW, Ubuntu trusty and precise both support HTTPS now (support was
> backported from trusty). wget would need to build a udeb in Debian
> and be able to take over /usr/bin/wget from busybox in d-i. I think
> the other changes are all in d-i parts. Basically you append trusted
> certs to the initramfs by specifying two initrds in the bootloader
> that are concatenated.
> 
> Somebody™ would need to do the work, though.

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.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720183026.ga15...@riva.ucam.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Philipp Kern

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 disabling HTTP is overdoing it.


FWIW, Ubuntu trusty and precise both support HTTPS now (support was 
backported from trusty). wget would need to build a udeb in Debian and 
be able to take over /usr/bin/wget from busybox in d-i. I think the 
other changes are all in d-i parts. Basically you append trusted certs 
to the initramfs by specifying two initrds in the bootloader that are 
concatenated.


Somebody™ would need to do the work, though.

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/74fc1c373ee2fe713a654169c129a...@hub.kern.lc



Bug#755430: ITP: prettify -- syntax highlighting of source code snippets in an html page

2014-07-20 Thread Dominique Dumont
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 : https://code.google.com/p/google-code-prettify/
* License : Apache-2.0
  Programming Lang: javascript
  Description : syntax highlighting of source code snippets in an html page

A Javascript module and CSS file that allows syntax highlighting of
source code snippets in an html page.

Features:

 * Works on HTML pages
 * Works even if code contains embedded links, line numbers, etc.
 * Simple API : include some JS&CSS and add an onload handler.
 * Customizable styles via CSS. See the themes gallery
 * Supports all C-like, Bash-like, and XML-like languages.
 * Extensible language handlers for other languages.
 * Widely used with good cross-browser support.

This lib is a dependency of libmojolicious-perl and will be hosted 
by pkg-javascript-team

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1691153.FScoRAugts@ylum



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Stefano Zacchiroli
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
enabled by default, plus a way for DDs to opt-out to the redirection
(dunno, by dropping .no-https-by-default files in suitable
sub-directories of ~/public_html) would nicely address the few
objections I've seen in this thread.

FWIW:

- it's not entirely clear how much extra work implementing this would
  require. In particular, I haven't put much thought in an easy way to
  implement the directory-level opt-out.

- I *personally* don't mind having https only, quite the contrary! But I
  got hooked by the discussions and couldn't resist proposing an API :)
  (sorry)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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 *disabling* the possibility of
> > > plain HTTP.
> > 
> > Pray tell: How do you make it default.
> 
> - Enable HSTS on the domain
> - Run "sed -i -e 's,http://people.debian.org,https://people.debian.org,g'"
>   over a webwml export.
> - Create a robots.txt file which is visible from the HTTP export (but
>   not from the HTTPS one) which looks like this:

None of these brings people who type in people.debian.org into their
browser to https.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720161914.gn...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Ondřej Surý
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 an HTTPS
> > connection that validates. Instead, I would only trust such a file if it
> > came with a GPG signature from a key that is in the Debian keyring.
> 
> Good, because that's not what HTTPS does for you.  It makes it more
> difficult to watch exactly what you're accessing.
> 
> Suppose for example I uploaded a preseed file to people.debian.org
> that created a Tor relay, and a suitably large government agency
> wanted to see all the IP addresses installing it.  With HTTP, they
> just break into the internet backbone at an appropriate point, and log
> every request for that file in a *completely undetectable manner*.
> With HTTPS, they either need to break into the machine running
> people.debian.org, or start presenting a different SSL certificate -
> both things which can potentially be detected.
> 
> Another situation is if a dissident accesses people.debian.org via
> Tor.  With HTTP, the operator of the exit node they are using could
> MITM the request and tamper with the file - no state intervention
> required.  If it's a web page, they could potentially attempt to
> exploit the browser.

[...]

This is excellent summary, thank you Tim. We should not forget that
the metadata are interesting too (and thus we also need dns privacy,
we don't have right now).

Also one of the reasons to encrypt everywhere is that it makes much
harder to decrypt everything. The more encrypted "noise" we have in
the background the better.

P.S.: And I am not known for my love for CAs :)...

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405869571.23682.143634353.4b92d...@webmail.messagingengine.com



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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 key material?
> >
> >Beyond GPG keys there are also DNSSEC private keys, SSL private keys,
> >and (to some extent) router administration passwords could also be
> >considered private keys.
> 
> Why would material of that kind (short of the SSL private key for the
> https server) be on p.d.o?

I didn't say that.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/23447020.uajmmu5...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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 *disabling* the possibility of
> > plain HTTP.
> 
> Pray tell: How do you make it default.

- Enable HSTS on the domain
- Run "sed -i -e 's,http://people.debian.org,https://people.debian.org,g'"
  over a webwml export.
- Create a robots.txt file which is visible from the HTTP export (but
  not from the HTTPS one) which looks like this:

  User-Agent: *
  Disallow: /

With those three easy steps, the only URLs that people will ever find
will be HTTPS URLs. 99% of your traffic will be HTTPS traffic, and that
will be a good thing. Yet when necessary, doing unencrypted HTTP will
still be possible.

It still misses something like step 2 for wiki.debian.org and "all other
stuff out there", but because of step 1 that shouldn't be *too* much of
a problem.

This will also help in, say, the (granted, hypothetical) scenario where
a package in unstable breaks the system so badly that downloading files
over HTTPS is no longer possible and a maintainer wants to post a
(GPG-signed) patch over on http://people.debian.org

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4187590.a2xdfsn...@grep.be



Re: How Debian should handle users requests?

2014-07-20 Thread Adam Borowski
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 report. A user may need to install third parties
> packages, and we are in the right to refuse supporting this. But we can
> not ask our users to be either a real hacker or to stop using our SW.

Except that in this case, to file a meaningful bug report, you need to be
able to:
* bisect the kernel
* attach a serial console (good luck even having the port these days)
and even that is likely to not be enough for kernel guys to fix this.

Suspend quirks are among worst bugs for a non-hacker to report.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720150102.ga17...@angband.pl



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Mirosław Baran

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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/c34936335ed61fa36ed5657b33eea...@hell.pl



Re: btrfs

2014-07-20 Thread Jeff Epler
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

Jeff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720134746.gb87...@unpythonic.net



btrfs

2014-07-20 Thread aberger588 .
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


Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)

2014-07-20 Thread Abou Al Montacir
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 means that your system hanged either during going into sleep mode
or when exiting the sleep mode. This is then not a screen issue but a
system issue. The fact that fans are on may indicate that the issue
happened when exiting suspend mode. But we definitely need more
information.
> Further after restart I found that nothing was written in neither
> dmesg 
dmesg does not remember messages from old boot, you need to relay on
logs
> nor pm-powersave.log after the lid is closed and then opened.
yes this is normal as you rebooted. Then this file will be filled for
the next time but you won't be able to recover it. Normally you should
find a /var/log/pm-*.log.1, these files are the ones you need to
provide.

Also it could be better if you try using the official Debian kernel, at
least while we are investigating the issue. I assume you have good
reason to use an other kernel, but we do not support such combinations,
so please ensure investigating this bug with:
(jessie)root@karim:~# aptitude show linux-image-amd64
Package: linux-image-amd64   
State: not installed
Version: 3.14+58
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team 
Architecture: i386
Uncompressed Size: 38.9 k
Depends: linux-image-3.14-1-amd64
Provides: linux-latest-modules-3.14-1-amd64
Description: Linux for 64-bit PCs (meta-package)
 This package depends on the latest Linux kernel and modules for use on
PCs with AMD64, Intel 64 or VIA Nano processors. 
 
 This kernel also runs on a Xen hypervisor.  It supports both privileged
(dom0) and unprivileged (domU) operation.

Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part


Re: Bug#755285: marked as done (general: Black screen on resume after suspend)

2014-07-20 Thread Chris Bannister
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 language is English, it would be a pity if the reader
made this mistake. Let's assume a modicum of 'common sense' at least.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720131209.GL12789@tal



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Peter Palfrader
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.


-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720122542.gl...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Iain R. Learmonth
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 *disabling* the possibility of
> > plain HTTP.
> 
> 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.

I am happy however to just use a seperate VHOST for non-HTTPS access.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpWSnHA5Gj2c.pgp
Description: PGP signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Iain R. Learmonth
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 very good reasons for not using HTTPS. You just
might not have thought of them yet.

[1]: https://lists.debian.org/debian-devel/2014/07/msg00480.html

The main one is that there are places in the world you just can't use HTTPS
for legal reasons and the second one being that there is hardware that just
can't handle HTTPS.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpL8mQaEmOf4.pgp
Description: PGP signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Iain R. Learmonth
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.
3 Attack is automated in a targeted fashion.

I don't see that this is beyond the realm of possibility. This is really
only a reason for having HTTPS as default, not excluding those who can't use
HTTPS for legal, technical or other reasons.

Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpeX09WD6eKd.pgp
Description: PGP signature


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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 *disabling* the possibility of
> plain HTTP.

Pray tell: How do you make it default.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720115220.gk...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Tollef Fog Heen
]] 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. So that argument
> simply doesn't apply.

There is no need for server-side HTTP scripts to run IRC in your
browser.  http://glowing-bear.github.io/glowing-bear/ talks to weechat,
for instance.

> Instead, people.d.o is a place to allow downloads of files. Period.

That's not the only thing people use it for, though.  They use it for
hosting web pages, their blog and so on.

> > > 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.
> > 
> > Not many HTTP clients support DANE, unfortunately, and MITM-ing
> > DNSSEC-secured domains is a bit more effort than just MITM-ing a
> > plaintext HTTP connection.
> 
> If you can MITM people.debian.org, you've already MITM'ed a
> DNSSEC-secured domain.

I see there's some confusion here.  I'm talking about a TCP level MITM
attack, not a DNS hijacking attack, which seems to be what you're
talking about.  Hijacking TCP is trivial and happens (intentionally and
by mistake) very, very often.

> > > > > Is there an actual attack vector that we're trying to protect against
> > > > > which requires us to disable plain HTTP, or is this just yet another
> > > > > instance of the bogus "HTTP is obsolete" idea?
> > > > 
> > > > There are lots of attack vectors.  It's not a response to a single
> > > > attack being exploited in the wild.
> > > 
> > > So name one?
> > 
> > To pick a random example off a web page:
> > http://ghantoos.org/2012/10/21/cocktail-of-pxe-debian-preseed-ipmi-puppet/
> > 
> > wget http://people.debian.org/~dannf/add-firmware-to/add-firmware-to
> > sed -i 's/lenny/wheezy/' add-firmware-to
> > chmod +x add-firmware-to
> > ./add-firmware-to initrd.gz initrd.nonfree.gz wheezy
> 
> The problem here is not the idea that someone might MITM
> people.debian.org and provide something useless. The problem is a
> culture of people who run random code off the web without checking what
> it does.

That is also a problem, yes.  Using HTTP makes it worse than if it was
using HTTPS.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2pph0qmq6@rahvafeir.err.no



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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 key material?
>
>Beyond GPG keys there are also DNSSEC private keys, SSL private keys,
>and (to some extent) router administration passwords could also be
>considered private keys.

Why would material of that kind (short of the SSL private key for the
https server) be on p.d.o?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1x8pij-0008ty...@swivel.zugschlus.de



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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
> >> > 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 access to private keys, and in
> >> this
> >> case you are so screwed.
> >
> >My point exactly: if someone can somehow MITM people.debian.org they
> >have access to private key material that they shouldn't have access to.
> 
> 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 private keys, SSL private keys,
and (to some extent) router administration passwords could also be
considered private keys.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/15798403.9o3vuy3...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Thijs Kinkhorst
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 implementation inside
>> > stable d-i does not support https, so downloading files from
>> > people.d.o (e.g., for preseeding) will become impossible if this is
>> > implemented as stated.
>>
>> Hopefully you're not preseeding from a HTTP source, since that means
>> you're quite vulnerable to trivial MITM attacks
>
> True, but debian-installer simply does not support any signed/encrypted
> preseeding.

If you insist on using http, you can also just host your preseed files on
http://grep.be. I don't see why DSA should wait to implement improvements
to Debian services while there are perfect alternatives available to suit
your use case.

Hosting stuff on people.debian.org gives it some air of legitimacy, "this
is approved by people associated with Debian". It only makes sense to me
that if we want to provide a service that associates content with Debian,
we make that service as secure and trustworthy as possible.


Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/862e3205c73028bb44e472d667cd80d6.squir...@aphrodite.kinkhorst.nl



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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 use only HTTPS.
> 
> I don't really follow that. A validating DNS resolver only makes sure
> you connect to the right IP address. DANE can specifiy the certificate
> to use for HTTPS, but you can't forward HTTP requests to HTTPS with
> DANE as far as I know.

If someone manages to break DNSSEC in such a way that they can redirect
your DNS requests to an IP address of their choosing, they can also
replace DANE records out from under your feet. But I agree that the
argument is somewhat weak. It's also not my core argument.

> In the case of HTTP a MITM attack can send a fake response to the HTTP
> request without the need for any key material/certificates or need to
> fake DNSSEC. For HTTPS it would need to have a certificate for
> people.debian.org that the client trusts.

True.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4767887.t6llxl5...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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 an HTTPS
> > connection that validates. Instead, I would only trust such a file if it
> > came with a GPG signature from a key that is in the Debian keyring.
> 
> Good, because that's not what HTTPS does for you.  It makes it more
> difficult to watch exactly what you're accessing.
> 
> Suppose for example I uploaded a preseed file to people.debian.org
> that created a Tor relay, and a suitably large government agency
> wanted to see all the IP addresses installing it.  With HTTP, they
> just break into the internet backbone at an appropriate point, and log
> every request for that file in a *completely undetectable manner*.
> With HTTPS, they either need to break into the machine running
> people.debian.org, or start presenting a different SSL certificate -
> both things which can potentially be detected.
> 
> Another situation is if a dissident accesses people.debian.org via
> Tor.  With HTTP, the operator of the exit node they are using could
> MITM the request and tamper with the file - no state intervention
> required.  If it's a web page, they could potentially attempt to
> exploit the browser.

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.

"There might be a reason why a user would want to use encryption" does
not negate "there might be a reason why a user would *not* want to use
encryption". I'm claiming the reasons as in the latter exist; one (and
not the least) of which is that downloading files off people.debian.org
from d-i preseeding happens today, is a valid use of that service, and
cannot be done if HTTP is disabled. If you think there aren't such valid
reasons, you either need to show me why my claim is wrong, or why the
costs to doing so outweigh the benefits. So far I haven't seen anyone do
that.

[...]

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1716734.flo03rq...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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 use only HTTPS.

I don't really follow that. A validating DNS resolver only makes sure
you connect to the right IP address. DANE can specifiy the certificate
to use for HTTPS, but you can't forward HTTP requests to HTTPS with
DANE as far as I know. 

In the case of HTTP a MITM attack can send a fake response to the HTTP
request without the need for any key material/certificates or need to
fake DNSSEC. For HTTPS it would need to have a certificate for
people.debian.org that the client trusts.


Kind regards,

Jeroen Dekkers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87silwjo6w.wl%jer...@dekkers.ch



Re: How Debian should handle users requests?

2014-07-20 Thread Jonathan Dowland
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? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720102928.ga28...@bryant.redmars.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Peter Palfrader
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 have migrated quite successfully.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720100747.gj...@anguilla.noreply.org



Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)

2014-07-20 Thread Aleksandar Nikolov


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 you please provide more information about your issue. As the screen
is dead I understand that you may have issue to provide the required
information depending on your computer skills. Please find below some
hints, and maybe Andrei can provide more hints instead of closing this
bug again ;)

If you have access to another computer, please consider logging into the
first one after resume (you need to have sshd installed or any other
deamon for remote access) then gain root access and provide output of
dmesg and other log files in /var/log like /var/log/pm-powersave.log.

I'm not a specialist of such issues, but don't like to have user's
request closed abruptly.

Cheers,
Abou Al Montacir

Hi Abou Al Montacir,

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.
Further after restart I found that nothing was written in neither dmesg 
nor pm-powersave.log after the lid is closed and then opened.


Best,
Aleksandar


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/11236581.3791405851031593.JavaMail.jmail@sarge



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Peter Palfrader
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 name one?
> 
> > Pervasive monitoring. Really we should introduce encryption
> > *everywhere*.
> 
> If this were DSA's position, I would disagree with it, but I would
> understand where they're coming from.  But DSA has *not* said that this is
> the reason for enforcing use of a protocol with significantly higher
> overhead.
> 
> I do think that if DSA are going to enforce such a policy, they should be
> able to explain why.

"What Ondřej said"


-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720100121.gi...@anguilla.noreply.org



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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
>> > 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 access to private keys, and in
>> this
>> case you are so screwed.
>
>My point exactly: if someone can somehow MITM people.debian.org they
>have access to private key material that they shouldn't have access to.

I might me missing something, and I admit not having read the entire
thread, but how would they have access to private key material?

_My_ GPG key has never been near people.debian.org, and I suspect that
key ring management would (rightfully!) promptly kick any public key
whose private key was found on p.d.o out of the keyring.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1x8nzn-0007a3...@swivel.zugschlus.de



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread 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 an HTTPS
> connection that validates. Instead, I would only trust such a file if it
> came with a GPG signature from a key that is in the Debian keyring.

Good, because that's not what HTTPS does for you.  It makes it more
difficult to watch exactly what you're accessing.

Suppose for example I uploaded a preseed file to people.debian.org
that created a Tor relay, and a suitably large government agency
wanted to see all the IP addresses installing it.  With HTTP, they
just break into the internet backbone at an appropriate point, and log
every request for that file in a *completely undetectable manner*.
With HTTPS, they either need to break into the machine running
people.debian.org, or start presenting a different SSL certificate -
both things which can potentially be detected.

Another situation is if a dissident accesses people.debian.org via
Tor.  With HTTP, the operator of the exit node they are using could
MITM the request and tamper with the file - no state intervention
required.  If it's a web page, they could potentially attempt to
exploit the browser.

>> > 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.

In this scenario, you gain that if the adversary wants to see what
you're doing with your HTTPS connection, they need to do something
potentially noticable like change the SSL certificate being offered.

> Again, I support enabling HTTPS, and I support making it the default
> if possible. I just don't think disabling plain HTTP is a good idea.

Annoyingly, unless d-i supports SSL (or runs Tor), taking this very
sensible move is rather inconvenient.

Another potential use for plain HTTP would be if we installed a Tor
hidden service on paradis, and published the address in a GPG-signed
message.  You would avoid the CA cartel, and have some assurance of
privacy.

Kind regards,

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadc0ge-agleh5eyfkm13mvfxhmumdpamcamofazbzqgashm...@mail.gmail.com



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Jakub Wilk

* 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.debian.org/~user/file

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720100359.ga6...@jwilk.net



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Steve Langasek
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 introduce encryption
> *everywhere*.

If this were DSA's position, I would disagree with it, but I would
understand where they're coming from.  But DSA has *not* said that this is
the reason for enforcing use of a protocol with significantly higher
overhead.

I do think that if DSA are going to enforce such a policy, they should be
able to explain why.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: How Debian should handle users requests?

2014-07-20 Thread Abou Al Montacir
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

Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part


Re: How Debian should handle users requests?

2014-07-20 Thread Abou Al Montacir
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 then filter more this kind of reports.
> 
> 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.
I perfectly understand that we are lacking time to maintain this or that
package, especially that on may loose too much time to follow mails on
d-d.

> > Then if the user reports a bug we need to understand it and try to fix
> > it. Maybe adding debian-user to the list of users monitoring bugs
> > against "general" pseudo package could also help in this case.
> 
> I think that would probably just add more noise to debian-devel.
> 
> -- 
> bye,
> pabs
Then I'd propose to have an other pseudo package "support" and a new
mailing list alias for d-u@l.d.o called for example support@d.o which
does not link to d-d@l.d.o and providing support for users.

This new pseudo package "support" can substitute to "general"
automatically by the tool after few messages are asked like:
  "I don't really know how to investigate this issue"
  "I'm not experienced user"
  ...

The main goal of all this is to make Debian more user friendly.

Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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-service such
> > > > > that
> > > > > only HTTPS connections will be supported (unencrypted requests will
> > > > > be
> > > > > redirected).
> > > > 
> > > > Why?
> > > 
> > > Because the world is a nastier place than it used to be.  It's like the
> > > move from telnet to SSH many moons ago, all protocols ought to be
> > > encrypted today.
> > 
> > Well, I disagree with that.
> > 
> > With telnet vs SSH, the move was necessary because telnet would send
> > passwords in the clear, and because telnet is mostly a control interface
> > rather than anything else.
> > 
> > With HTTP vs HTTPS, the move can be necessary (many control interfaces
> > these days are written in HTTP server-side code, and then using plain
> > HTTP is a bad idea), but I doubt the majority of uses for
> > people.debian.org is anything but downloading static files these days.
> 
> I don't see a big difference between reading mail in pine, which people
> did using telnet and reading mail in their browser over HTTP.  Or IRC
> and twitteresque services.

Oh sure, I agree that in those cases it makes perfect sense to disable
plain HTTP. But that's not what this is.

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. So that argument
simply doesn't apply.

Instead, people.d.o is a place to allow downloads of files. Period.
Sometimes it should be possible to verify that these files have not been
tampered with. 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 trust such a file if it
came with a GPG signature from a key that is in the Debian keyring.

> (I wouldn't call things like mail clients and social media control
> interfaces either.)

Well, I would, but that's just semantics, and so has little relevance in
this discussion.

> > It's good to make HTTPS the default, which if you must you can do
> > (amongst other things) by way of HSTS. However, I fail to see why we
> > should make HTTP impossible for those cases where it's needed.
> 
> Would you be happy with
> http://people.debian.org/THIS-IS-INSECURE/YES-I-WANT-TO-PROCEED/~user/file
> as the URLs?  We could do something like that, where if you absolutely
> must use HTTP, you can, but it's more annoying and tedious than the
> better alternative.

I suppose that could work, although it might make HSTS fail (but I must
admit I don't understand HSTS in detail).

[...]
> > 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.
> 
> Not many HTTP clients support DANE, unfortunately, and MITM-ing
> DNSSEC-secured domains is a bit more effort than just MITM-ing a
> plaintext HTTP connection.

If you can MITM people.debian.org, you've already MITM'ed a
DNSSEC-secured domain.

> > > > Is there an actual attack vector that we're trying to protect against
> > > > which requires us to disable plain HTTP, or is this just yet another
> > > > instance of the bogus "HTTP is obsolete" idea?
> > > 
> > > There are lots of attack vectors.  It's not a response to a single
> > > attack being exploited in the wild.
> > 
> > So name one?
> 
> To pick a random example off a web page:
> http://ghantoos.org/2012/10/21/cocktail-of-pxe-debian-preseed-ipmi-puppet/
> 
> wget http://people.debian.org/~dannf/add-firmware-to/add-firmware-to
> sed -i 's/lenny/wheezy/' add-firmware-to
> chmod +x add-firmware-to
> ./add-firmware-to initrd.gz initrd.nonfree.gz wheezy

The problem here is not the idea that someone might MITM
people.debian.org and provide something useless. The problem is a
culture of people who run random code off the web without checking what
it does. That ghantoos.org thing might refer to people.deb1an.org
instead which contains nothing but malware; if you download and run code
off the internet without checking it, you've already lost. This isn't
very special in that regard, and that's not something you can fix by
forcing HTTPS on people.

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.

Again, I support enabling HTTPS, and I support making it the default
if possible. I just don't think disabling plain HTTP is a good ide

Re: How Debian should handle users requests?

2014-07-20 Thread Abou Al Montacir
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
> >> forum. The consensus for dealing with user support requests being filed
> >> as "general" bugs has always been "close the bug and instruct the user
> >> to contact a support forum, mainly debian-user". When what the user is
> >> seeing turns out to be a bug in some package debian-user can also help
> >> with producing an actionable bug report against that package. Perhaps
> >> this needs to be documented more prominently?
> >
> > While I agree that the pseudo package "general" shall not be used as a
> > help forum, I don't like to close a bug abruptly. Also in this case the
> > current bug we are dealing with is probably a real bug.
> 
> It might indeed be a real bug, but not in any Debian package. I don't
> know what distribution the user runs, but his kernels come from an
> Ubuntu PPA. In any case "something no longer works but I have no idea
> how to find out what" isn't an actionable bug report, it's a request for
> support.
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 report. A user may need to install third parties
packages, and we are in the right to refuse supporting this. But we can
not ask our users to be either a real hacker or to stop using our SW.

> > 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 then filter more this kind of reports.
> >
> > Then if the user reports a bug we need to understand it and try to fix
> > it. Maybe adding debian-user to the list of users monitoring bugs
> > against "general" pseudo package could also help in this case.
> 
> I don't think reportbug should allow filing bugs against general at
> all. The extremely rare cases when one is needed can be filed manually.
> 
> -- 
> Arto Jantunen
This is probably a valid point. If you consider reports against general
as for experienced users only then make reportbug(-ng) refuse filling
bugs against them and send rather a request to d-u or even better,
create a separate DB for support, a kind of BTS coupled with d-u.

Cheers,
Abou Al Montacir



signature.asc
Description: This is a digitally signed message part


Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Wouter Verhelst
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 much.
> 
> But that implies that the attacker has access to private keys, and in
> this
> case you are so screwed.

My point exactly: if someone can somehow MITM people.debian.org they
have access to private key material that they shouldn't have access to.

> The possibility of stolen private keys should not be argument for not
> implementing security.

I'm not against implementing security -- I'm against forcing https where
it makes no sense.

> > > 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 introduce encryption
> *everywhere*.

I realize that in these days of Snowden and similar things it is
fashionable to say that there's someone snooping every connection
everywhere, but I don't think that's a) a very strong argument, or b)
blocked by use of HTTPS (if the "pervasive monitoring" kind of people
like the NSA want to, they'll just subpoena those who have access to the
secret data and get what they want).

Additionally, and again, I'm not against allowing HTTPS for those who
want to make pervasive monitoring harder--I'm against disabling plain
HTTP just for the sake of it. Sure, enable HTTPS, and yeah, sure, enable
HSTS too. But disabling HTTP? That doesn't serve any useful purpose.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1915517.jyrk2gy...@grep.be



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Matthias Urlichs
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. if you're using basic-auth or similar cleartext
password schemes on the link. Otherwise, not so much.

In other words: please add HTTPS capabilities to d-i before you do that.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140720083823.gd15...@smurf.noris.de



Bug#755386: ITP: fonts-adobe-sourcehansans-kr -- “Source Han Sans KR” A sans-serif Pan-CJK font family (KR subset) that is offered in seven weights

2014-07-20 Thread LIU Dongyuan
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 Sans KR” A sans-serif Pan-CJK font family
(KR subset) that is offered in seven weights

Source Han Sans is a sans serif Pan-CJK font family that is offered in seven
weights—ExtraLight, Light, Normal, Regular, Medium, Bold, and Heavy—and in
several OpenType/CFF-based deployment configurations to accommodate various
system requirements or limitations. As the name suggests, Pan-CJK fonts are
intended to support the characters necessary to render or display text in
Simplified Chinese, Traditional Chinese, Japanese, and Korean.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140720081614.23252.97860.reportbug@csvenja-lenovo



Bug#755383: ITP: fonts-adobe-sourcehansans-twhk -- “Source Han Sans TWHK” A sans-serif Pan-CJK font family (TWHK subset) that is offered in seven weights

2014-07-20 Thread LIU Dongyuan
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 Han Sans TWHK” A sans-serif Pan-CJK font family
(TWHK subset) that is offered in seven weights

Source Han Sans is a sans serif Pan-CJK font family that is offered in seven
weights—ExtraLight, Light, Normal, Regular, Medium, Bold, and Heavy—and in
several OpenType/CFF-based deployment configurations to accommodate various
system requirements or limitations. As the name suggests, Pan-CJK fonts are
intended to support the characters necessary to render or display text in
Simplified Chinese, Traditional Chinese, Japanese, and Korean.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140720080813.23064.91484.reportbug@csvenja-lenovo



Bug#755385: ITP: fonts-adobe-sourcehansans-jp -- “Source Han Sans JP” A sans-serif Pan-CJK font family (JP subset) that is offered in seven weights

2014-07-20 Thread LIU Dongyuan
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 Sans JP” A sans-serif Pan-CJK font family
(JP subset) that is offered in seven weights

Source Han Sans is a sans serif Pan-CJK font family that is offered in seven
weights—ExtraLight, Light, Normal, Regular, Medium, Bold, and Heavy—and in
several OpenType/CFF-based deployment configurations to accommodate various
system requirements or limitations. As the name suggests, Pan-CJK fonts are
intended to support the characters necessary to render or display text in
Simplified Chinese, Traditional Chinese, Japanese, and Korean.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140720081347.23153.19831.reportbug@csvenja-lenovo



Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

2014-07-20 Thread LIU Dongyuan
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 Sans CN” A sans-serif Pan-CJK font family
(CN subset) that is offered in seven weights

Source Han Sans is a sans serif Pan-CJK font family that is offered in seven
weights—ExtraLight, Light, Normal, Regular, Medium, Bold, and Heavy—and in
several OpenType/CFF-based deployment configurations to accommodate various
system requirements or limitations. As the name suggests, Pan-CJK fonts are
intended to support the characters necessary to render or display text in
Simplified Chinese, Traditional Chinese, Japanese, and Korean.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140720075903.22860.54583.reportbug@csvenja-lenovo



Re: people.debian.org will move from ravel to paradis and become HTTPS only

2014-07-20 Thread Ondřej Surý
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 access to private keys, and in
this
case you are so screwed. The possibility of stolen private keys should
not be argument for not implementing security.

> > 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 introduce encryption
*everywhere*.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405841035.16130.143560421.61491...@webmail.messagingengine.com