Re: people.debian.org will move from ravel to paradis and become HTTPS only
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
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
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
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
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#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
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#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
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
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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: How Debian should handle users requests?
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
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?
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: How Debian should handle users requests?
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: people.debian.org will move from ravel to paradis and become HTTPS only
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: people.debian.org will move from ravel to paradis and become HTTPS only
* 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
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
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
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
Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)
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
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
Re: How Debian should handle users requests?
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
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: people.debian.org will move from ravel to paradis and become HTTPS only
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
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
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
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
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
]] 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
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
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
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
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
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: Bug#755285: marked as done (general: Black screen on resume after suspend)
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
Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)
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
btrfs
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
Re: btrfs
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
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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: How Debian should handle users requests?
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
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: people.debian.org will move from ravel to paradis and become HTTPS only
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
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
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
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
Bug#755430: ITP: prettify -- syntax highlighting of source code snippets in an html page
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
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
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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
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
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
-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
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
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
Bug#755286: Bug#755285: marked as done (general: Black screen on resume after suspend)
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
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
Re: people.debian.org will move from ravel to paradis and become HTTPS only
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
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: Bug#755285: marked as done (general: Black screen on resume after suspend)
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: 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
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#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
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#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
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#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
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#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
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: How Debian should handle users requests?
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: people.debian.org redirecting browsers to HTTPS (was: people.debian.org will move from ravel to paradis and become HTTPS only)
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
