Bug#840814: ITP: python-bitbucket-api -- library to interact with bitbucket API
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: python-bitbucket-api Version : 0.5.0 Upstream Author : Name * URL : https://github.com/Sheeprider/BitBucket-api * License : ISC Programming Lang: Python Description : library to interact with bitbucket API python-bitbucket-api provides an API to use the following features in bitbucket: * Access public user informations * Access public or private repositories, tags or branches * Create, update or delete one of your repository * Access, create, update or delete a service (hook) * Access, create or delete an SSH key * Download a repository as an archive * Access, create, update or delete an issue * Access, create, update or delete an issue comment -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Update GnuPG failed
Hello, since tha update on thursday I can't use GPG on Stretch. There is gpg version 2.1.15-4. Unter Jessie all things are fine with gpg 1.4.18 Unter Stretch I have no access to my private key and the public keyring. I only see the keys which incomes with the mails after the update What happens? The files of the secret key and the public keyring are identical with the backup and at the Jessie machine. What is the best way to fix it? Kind regards Mechtilde Stehmann -- ## Apache OpenOffice.org ## Freie Office Suite für Linux, MacOSX, Windows ## Debian ## Loook, calender-exchange-provider, libreoffice-canzeley-client ## PGP encryption welcome ## Key-ID 0x141AAD7F
Re: Update GnuPG failed
On Sat, 15 Oct 2016, Mechtilde wrote: > There is gpg version 2.1.15-4. > Unter Jessie all things are fine with gpg 1.4.18 > > Unter Stretch I have no access to my private key and the public keyring. > I only see the keys which incomes with the mails after the update > > What happens? The files of the secret key and the public keyring are > identical with the backup and at the Jessie machine. > > What is the best way to fix it? Please direct this kind of question to the debian-users mailinglist... -- Henrique Holschuh
Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes
Lots of this discussion has been focusing on the test suite process leak problem. But there are actually three separate use cases which need something along the lines of my proposal; two of which are regressions from gnupg1. 1. gnupg1-compatible authorisation lifetime: Command line use of gpg by users outside of a desktop environment (or who have disabled desktop environment passphrase sharing). With gnupg1 each call to gpg to sign or decrypt something would ask for the user's authorisation for the specific action. This is, in many (if not most) contexts a desirable security property. (It's valuable even, or particularly, if none of the software invoking gpg is malicious: because software can do unexpected things for other reasons than malice.) There should be a way for command line users (including users of programs which themselves call gnupg) to have the same authorisation lifetime as with gnupg1. Personally I think this should be the default, at least if there is no ambient gpg-agent found. But even if it is not going to be the default it should be available as a configuration option. I don't think any of the approaches advanced in this thread are able to provide the gnupg1 authorisation lifetime model. So this is a regression in gnupg2 which is not addressed by any of the proposals other than mine. This is an especially serious regression in that in this use case gnupg2 (currently) silently extends the scope of an authorisation in an unexpected way. 2. Explicit programmatic control of authorisation lifetime: Programs like debsign and dgit want to do what is in their model a single high-level operation but which at the crypto level involves multiple decryptions and/or sigantures. It would be nice if such a program could, when invoked in a setup without ambient authorisation, explicitly request authorisation once and then apply it multiple times. This is feature which is not present in gnupg1 (at least not without a lot of explicit code to set up and tear down an agent), but which would be useful and which I think cannot be provided by any of the proposals other than mine. 3. Test suite process leakage. This has been discussed extensively. There are proposals including use of inotify, explicit teardown by tools like schroot, and so on, which address this use case. They are not 100% perfect but would probably suffice. Thanks for your attention. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
uscan download from sourceforge doesn't download what you expect!
... at least not for boost. I downloaded the latest release manually by following the links from boost.org to https://sourceforge.net/projects/boost/files/boost/1.62.0/ boost_1_62_0.tar.bz2/download Then I remembered that Dimitri had written a watch file to use the Files- Excluded facility. So I ran uscan. This leaves me the original download as well as the re-packed tarball. Comparing the original download to my manual download indicated many differences. Running uscan with --verbose led me to the reflector page https:// qa.debian.org/watch/sf.php/boost/ used by uscan. The boost_1_62_0.tar.bz2 link on that page leads to https://sourceforge.net/projects/boost/files/boost/ snapshots/master/boost_1_62_0.tar.bz2/download Notice the crucial difference: the reflector is using "boost/snapshots/master" whereas the correct URL uses "boost/1.62.0". The snapshots are pulled from the branch tip and are NOT actual releases. So the reflector is listing bad URLs. Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? Note: I didn't look, so I have no idea if this is a widespread problem with the watch reflector. I'd suggest that people do a spot-check on their own packages to see. Thanks, -Steve signature.asc Description: This is a digitally signed message part.
When should we https our mirrors?
Howdy -devel, It's that time of the year again - that's right, another paultag rant with some grand ideas about the state of the world. It seems like every month or so, someone pops into a channel and asks why we aren't using https on our mirrors. This well-meaning question is usually met with hositility (We do integrety checks via out of band OpenPGP signatures, and mirrors aren't assumed to be private so knowing what you have installed is nbd, some exotic pet arches may take a few more CPU cycles to handshake) and associated pushback. I find most of these arguments pretty boring, and I don't think the "costs" outweigh the benefits. I see no reason why the argument that the mirror server may be compromised means we have to open ourselves up to trivial MITM and installed packages / versions disclosure to everyone between me and the server. I see no reason why just because we check signatures later that I put random data from the internet into memory and on disk, and run a program over it without making sure it's at least the server I think I'm talking to. I see no reason why exotic pet arches that already take huge cycles to process data are a reason to keep back the vast majority of our install base. So, the real question: So, when are we going to push this? If not now, what criteria need to be met? Why can't we https-ify the default CDN mirror today? (Sadly this means my trick to MITM the debian mirrors with my LAN mirror breaks, but this strikes me as a feature not a bug) Toodles, paultag signature.asc Description: PGP signature
Re: uscan download from sourceforge doesn't download what you expect!
On 15 October 2016 at 18:47, Steve M. Robbins wrote: > ... at least not for boost. > > I downloaded the latest release manually by following the links from boost.org > to https://sourceforge.net/projects/boost/files/boost/1.62.0/ > boost_1_62_0.tar.bz2/download > Yes, this is known to me, but I did not report. The redirector / sourceforge make it hard to distinct identically named files in different subfolders unfortunately. I did too manually repackaged wrong tarballs by hand. There is also possibly an upstream bug, because they name pre-release snapshots identically to final released version number. Regards, Dimitri. > Then I remembered that Dimitri had written a watch file to use the Files- > Excluded facility. So I ran uscan. This leaves me the original download as > well as the re-packed tarball. Comparing the original download to my manual > download indicated many differences. > > Running uscan with --verbose led me to the reflector page https:// > qa.debian.org/watch/sf.php/boost/ used by uscan. The boost_1_62_0.tar.bz2 > link on that page leads to https://sourceforge.net/projects/boost/files/boost/ > snapshots/master/boost_1_62_0.tar.bz2/download > > Notice the crucial difference: the reflector is using "boost/snapshots/master" > whereas the correct URL uses "boost/1.62.0". The snapshots are pulled from > the branch tip and are NOT actual releases. So the reflector is listing bad > URLs. > > Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? > > Note: I didn't look, so I have no idea if this is a widespread problem with > the watch reflector. I'd suggest that people do a spot-check on their own > packages to see. > > Thanks, > -Steve > -- Regards, Dimitri.
Re: When should we https our mirrors?
On 15 October 2016 at 19:03, Paul Tagliamonte wrote: > > So, the real question: > > So, when are we going to push this? If not now, what criteria need to be > met? Why can't we https-ify the default CDN mirror today? > It is my understanding that in 2016 there is a huge difference between the following sniffed traffic information: a) TLS traffic from a server to archive.debian.org host b) HTTP traffic from a server to archive.debain.org/debian-security/dists/lenny Since the latter reveals that the system is likely to be susceptible to every single CVE since Lenny end of life. I believe the TLS overhead costs are negligible, especially if one uses ECC keys. The further privacy it buys one, is IMHO, well worth the effort. I would be in favor of Debian mirrors to auto-enroll into letsencrypt certs. -- Regards, Dimitri.
Re: When should we https our mirrors?
There's nothing stopping mirror operators from enabling HTTPS. Some of them actually have done it already: https://crt.sh/?q=ftp%25.%25.debian.org (and there's more in non-*.debian.org domains) We should have an official list of HTTPS mirrors, and encourage more operators to enable it. On a semi-unrelated note: Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and sometimes non-free) software that is not Debian[*]. This may mislead inexperienced people into thinking that this software is endorsed or even produced by Debian. Should we insist that only Debian is served from these domains? [*] See e.g.: https://ftp.se.debian.org/ -- Jakub Wilk
Re: When should we https our mirrors?
]] Paul Tagliamonte > So, when are we going to push this? If not now, what criteria need to > be met? Why can't we https-ify the default CDN mirror today? The usual crypto answer: because key handling is hard. Doing this for the per-country mirrors means that repointing mirrors becomes a lot harder than it currently is, and this is something we do on a daily basis. We'd need a solution for deploying the TLS cert for, say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for maintenance. Doing this for deb.d.o would mean we need to get certs on both Fastly and Cloudfront deployed, which is, frankly, a more realistic proposition than jury-rigging something on the per-country mirrors. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#840893: ITP: ansible-tower-cli -- command line tool for Ansible Tower
Package: wnpp Severity: wishlist Owner: Evgeni Golov * Package name: ansible-tower-cli Version : 3.0.1 Upstream Author : Luke Sneeringer * URL : https://github.com/ansible/tower-cli * License : Apache 2.0 Programming Lang: Python Description : command line tool for Ansible Tower tower-cli is a command line tool for Ansible Tower. It allows Tower commands to be easily run from the Unix command line. It can also be used as a client library for other python apps, or as a reference for others developing API interactions with Tower's REST API. . This command line tool sends commands to the Tower API. It is capable of retrieving, creating, modifying, and deleting most objects within Tower. . A few potential uses include: * Launching playbook runs * Checking on job statuses * Rapidly creating objects like organizations, users, teams and more
Re: uscan download from sourceforge doesn't download what you expect!
On Sat, Oct 15, 2016 at 12:47:21PM -0500, Steve M. Robbins wrote: > Notice the crucial difference: the reflector is using > "boost/snapshots/master" > whereas the correct URL uses "boost/1.62.0". The snapshots are pulled from > the branch tip and are NOT actual releases. So the reflector is listing bad > URLs. This is really upstream doing something they should really not do: version pre-releases the same as released stuff; also same filename… > Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? look at the bottom of that page, there are links to the code; then send a patch qa.debian.org's way (or try to report a patch-less bug). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#840897: general: framebuffer modules for non-dri graphics cards are not loaded
Package: general Severity: normal Hello, I dusted off a notebook with hardware serial port which also happens to have a Mach64 graphics card. Accidentally during system upgrade an extra display manager was installed which broke the text console. Running two X servers without KMS is problematic. Upstream has a solution that should prevent most of these problems. The current X drivers seem to work reasonably well with fbdev so long as the fb module is loaded before the X server is started. At least the Mach64 driver looks ok. Since the X driver appears to have fbdev integration it should not break the console so long as fbdev is available. Unfortunately, atyfb is not loaded by Debian. What's worse, adding the driver to /etc/modules or /etc/initramfs-tools/modules has no effect. The module is not loaded. So I would like the fbdev modules removed from whatever blacklist prevents loading them and have them loaded on systems that don't have dri modules to handle graphics. Thanks -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: When should we https our mirrors?
On Oct 15, Dimitri John Ledkov wrote: > I believe the TLS overhead costs are negligible, especially if one This is not about the TLS overhead: the real issue is not being able to use sendfile(2). > uses ECC keys. The further privacy it buys one, is IMHO, well worth > the effort. I would be in favor of Debian mirrors to auto-enroll into > letsencrypt certs. This would fail spectacularly due to the per-domain rate limiting imposed by LE. -- ciao, Marco signature.asc Description: PGP signature
requiring vhosts (was: Re: When should we https our mirrors?)
On Sat, Oct 15, 2016 at 09:24:15PM +0200, Jakub Wilk wrote: > Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and sometimes > non-free) software that is not Debian[*]. This may mislead inexperienced > people into thinking that this software is endorsed or even produced by > Debian. Should we insist that only Debian is served from these domains? > > > [*] See e.g.: https://ftp.se.debian.org/ Compare https://ftp.se.debian.org with https://ftp.acc.umu.se/ -- these look quite similar to me... The real reason is suggested by the "ftp." prefix: the site historically was supposed to be used via ftp, and still supports it. And ftp doesn't have such a thing as vhosts. Requiring a dedicated v4 IP is not a burden for a big 1st world mirror, but might be problematic for someone smaller, especially if they carry a number of projects other than Debian. Meow! -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: When should we https our mirrors?
Marco d'Itri wrote: > On Oct 15, Dimitri John Ledkov wrote: > > I believe the TLS overhead costs are negligible, especially if one > This is not about the TLS overhead: the real issue is not being able to > use sendfile(2). If you really want to use sendfile (or splice or vmsplice) for your TLS connections, see AF_ALG and https://lwn.net/Articles/666509/ . However, I seriously doubt that any Debian mirror will become CPU-bound doing TLS before it saturates available network or disk bandwidth. > > uses ECC keys. The further privacy it buys one, is IMHO, well worth > > the effort. I would be in favor of Debian mirrors to auto-enroll into > > letsencrypt certs. > This would fail spectacularly due to the per-domain rate limiting > imposed by LE. Let's Encrypt has a process to request lifting that rate limit, and I imagine they'd have no problem doing so for debian.org subdomains.
Re: uscan download from sourceforge doesn't download what you expect!
On Sun, Oct 16, 2016 at 1:47 AM, Steve M. Robbins wrote: > Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? These days the reflector is just a proxy for the sourceforge RSS feeds: https://sourceforge.net/projects/boost/rss?limit=1000 So check if the issue occurs in their RSS feed before sending a bug or patch. -- bye, pabs https://wiki.debian.org/PaulWise
Re: When should we https our mirrors?
On Sun, Oct 16, 2016 at 2:03 AM, Paul Tagliamonte wrote: > So, when are we going to push this? If not now, what criteria need to be > met? Why can't we https-ify the default CDN mirror today? Exactly what actions do you mean by this? Debian does not control what mirror operators do, they are free to add https or not. Some do but most don't. httpredir.d.o is not well maintained, but it could theoretically support https if someone cared about it. deb.d.o is backed by two commercial CDNs, see Tollef's mail about that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: When should we https our mirrors?
On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote: > Doing this for the per-country mirrors means that repointing mirrors > becomes a lot harder than it currently is, and this is something we do > on a daily basis. We'd need a solution for deploying the TLS cert for, > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for > maintenance. I never really liked the per-country mirrors being under debian.org, redirectors would be a better option. I think we really need to redesign the apt archive namespace for Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: When should we https our mirrors?
On Sunday, October 16, 2016, Tollef Fog Heen wrote: > ]] Paul Tagliamonte > > > So, when are we going to push this? If not now, what criteria need to > > be met? Why can't we https-ify the default CDN mirror today? > > The usual crypto answer: because key handling is hard. > > Doing this for the per-country mirrors means that repointing mirrors > becomes a lot harder than it currently is, and this is something we do > on a daily basis. We'd need a solution for deploying the TLS cert for, > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for > maintenance. > > I agree key handling is difficult, but it's not that hard to work around such scenarios when HTTP 302 can be provided from the original maintianers (i.e. through a temporary virtual machine). Actually we have backup plan on ftp.cn.d.o and ftp2.cn.d.o that is battle-tested. They would redirect traffic to selected mirrors in a way similar to httpredir.d.o when outages happen. Performance and bandwidth requirements are acceptable for a temporary service even they are of the busiest FOSS mirrors in China. The two mirrors are delivering most of the traffic through HTTPS nowadays according to statistics because we've deployed User-Agent based HTTPS redirection on all supported domains and never heard a complain. Overhead is negligible because IOPS of disk arrays is always the most significant problem and bandwidth the next. > Doing this for deb.d.o would mean we need to get certs on both Fastly > and Cloudfront deployed, which is, frankly, a more realistic proposition > than jury-rigging something on the per-country mirrors. > > There's no reason to not do it, but it doesn't cover parts in the world like China where neither Fastly nor Cloudfront provides a decent service. Best, Aron
Re: When should we https our mirrors?
On Sunday, October 16, 2016, Paul Wise wrote: > On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote: > > > Doing this for the per-country mirrors means that repointing mirrors > > becomes a lot harder than it currently is, and this is something we do > > on a daily basis. We'd need a solution for deploying the TLS cert for, > > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for > > maintenance. > > I never really liked the per-country mirrors being under debian.org, > redirectors would be a better option. I think we really need to > redesign the apt archive namespace for Debian. > > > Yeah but at the risk of making it broken like pypi and npm to quite some people including me. Best, Aron -- Regards, Aron Xu
Bug#840907: ITP: winregfs -- Windows registry FUSE filesystem
Package: wnpp Severity: wishlist Owner: Giovani Augusto Ferreira * Package name: winregfs Version : 0.6 Upstream Author : Jody Bruchon * URL : https://github.com/jbruchon/winregfs * License : GPL-2 Programming Lang: C Description : Windows registry FUSE filesystem winregfs is a FUSE-based filesystem driver that enables accessing of Windows registry hive files as ordinary filesystems. Registry hive file editing can be performed with ordinary shell scripts and command-line tools once mounted. . fsck.winregfs scans a Windows registry hive file for problems that indicate the hive has been damaged by hardware or software issues, reading recursively the key and value data structures in the registry hive. . This package is useful for pentesters, ethical hackers and forensics experts.
dput: Call for testers: replacing ‘/usr/bin/gpg’ with GPGME
Howdy all, I am preparing a new version of ‘dput’ that stops using ‘/usr/bin/gpg’, and instead uses the GPGME library for GnuPG operations. Currently, as of ‘dput’ version 0.10, GnuPG operations are done by invoking the ‘/usr/bin/gpg’ command in a subprocess. This is fragile in several ways, not least that it depends on stream output from the command to determine the result of operations. I expect GPGME https://gnupg.org/related_software/gpgme/> will make it easier for ‘dput’ to support more systems. So I am preparing a version of ‘dput’ > 0.10 that will stop using a specific command path in a subprocess, and instead use the library API. Before the release I would like to have some testers try the program for regressions. If your packaging workflow has unusual signing practices, or an unusual GnuPG configuration, your help will be especially valuable to test this change. Please contact me at to offer your packaging system to test this new release. -- \“Sane people have an appropriate perspective on the relative | `\ importance of foodstuffs and human beings. Crazy people can't | _o__) tell the difference.” —Paul Z. Myers, 2010-04-18 | Ben Finney
Re: When should we https our mirrors?
On Sunday, October 16, 2016, Aron Xu wrote: > > > On Sunday, October 16, 2016, Paul Wise > wrote: > >> On Sun, Oct 16, 2016 at 3:25 AM, Tollef Fog Heen wrote: >> >> > Doing this for the per-country mirrors means that repointing mirrors >> > becomes a lot harder than it currently is, and this is something we do >> > on a daily basis. We'd need a solution for deploying the TLS cert for, >> > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for >> > maintenance. >> >> I never really liked the per-country mirrors being under debian.org, >> redirectors would be a better option. I think we really need to >> redesign the apt archive namespace for Debian. >> >> >> > Yeah but at the risk of making it broken like pypi and npm to quite > some people including me. > > To make it clear, content delivery systems used by pypi and npm don't work for many people in China because: 1) Major global CDN providers don't have decent services in the country (except akamai and cloudflare but need special contract); 2) BGP based network topology discovery never work because eBGP routing is not widely deployed for subscriber network; There's more to mention for Debian: 3) cdn.debian.net / httpredir.d.o tend to exclude local mirrors because of the synchronization delays are much higher than in EU/US, even current ftpX.cn.d.o would easily exceed the tolerance of redirecting software. Best Aron
Re: uscan download from sourceforge doesn't download what you expect!
On Sun, Oct 16, 2016 at 2:49 AM, Dimitri John Ledkov wrote: > Yes, this is known to me, but I did not report. The redirector / > sourceforge make it hard to distinct identically named files in > different subfolders unfortunately. This was a bug in the redirector, I've added additional links containing the full path to the files. I couldn't modify the existing links because that would break all existing sf.net using watch files. I added a direct link to the sourceforge-run redirector too, so these should both work: version=3 opts="uversionmangle=s/_/./g,dversionmangle=s/\+dfsg$//" \ http://sf.net/boost/ .*/[.\d]+/boost_([\d_]*)\.tar.bz2 version=3 opts="uversionmangle=s/_/./g,dversionmangle=s/\+dfsg$//" \ http://sf.net/boost/ https://downloads.sourceforge.net/.*/[.\d]+/boost_([\d_]*)\.tar.bz2 -- bye, pabs https://wiki.debian.org/PaulWise
Bug#840915: ITP: python-github3.py -- comprehensive, actively developed and extraordinarily stable wrapper around the GitHub API (v3)
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: python-github3.py Version : 0.9.3 Upstream Author : Ian Cordasco (sigmavirus24) * URL : https://github.com/sigmavirus24/github3.py * License : BSD-3-clause Programming Lang: Python Description : Python stable wrapper around the GitHub API (v3) github3.py is a comprehensive, actively developed and extraordinarily stable wrapper around the GitHub API (v3). -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Re: When should we https our mirrors?
On 15 October 2016 at 20:25, Tollef Fog Heen wrote: > ]] Paul Tagliamonte > >> So, when are we going to push this? If not now, what criteria need to >> be met? Why can't we https-ify the default CDN mirror today? > > The usual crypto answer: because key handling is hard. > > Doing this for the per-country mirrors means that repointing mirrors > becomes a lot harder than it currently is, and this is something we do > on a daily basis. We'd need a solution for deploying the TLS cert for, > say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for > maintenance. > I'm not a sysadmin. My naive approach would be to have cname specified on the certs that are subject to redirect. E.g. ftp.d.o should have cname's for all country codes, such that any country mirror can fall back to ftp.d.o. Yes, it means that ftp.d.o can impersonate country mirrors. However, we validate the integrity of the archive via gpg, this TLS thing is only to encrypt the channel for the privacy of the requests. > Doing this for deb.d.o would mean we need to get certs on both Fastly > and Cloudfront deployed, which is, frankly, a more realistic proposition > than jury-rigging something on the per-country mirrors. > > -- > Tollef Fog Heen > UNIX is user friendly, it's just picky about who its friends are > -- Regards, Dimitri.
Bug#840916: ITP: node-buffer-equal -- return whether two buffers are equal
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-buffer-equal Version : 1.0.0 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/node-buffer-equal * License : Expat Programming Lang: JavaScript Description : return whether two buffers are equal
Bug#840917: ITP: tongue -- Lua I18N library 'Tongue'
Package: wnpp Severity: wishlist Owner: Daniel Silverstone * Package name: tongue Version : 0.8 Upstream Author : Daniel Silverstone * URL : https://git.gitano.org.uk/tongue.git * License : BSD Programming Lang: Lua Description : Lua I18N library 'Tongue' Tongue is an internationalisation engine written in Lua which implements a hierarchical language pack system for Lua programs to use in localising messages into and out of themselves. This package is a dependency of Gitano which I am trying to get packaged into Stretch. This is the last dependency which needs adding to Debian as far as I can tell, before Gitano can go in. I will be maintaining the package myself to begin with; though I do have two potentially interested others for co-maintenance. D.
Bug#840918: ITP: node-string-decoder -- The string_decoder module from Node core
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-string-decoder Version : 0.10.31 Upstream Author : FIX_ME upstream author * URL : https://github.com/rvagg/string_decoder * License : Expat Programming Lang: JavaScript Description : The string_decoder module from Node core
Re: When should we https our mirrors?
]] Dimitri John Ledkov > I'm not a sysadmin. My naive approach would be to have cname specified > on the certs that are subject to redirect. E.g. ftp.d.o should have > cname's for all country codes, such that any country mirror can fall > back to ftp.d.o. This would restrict us to always point a ftp.XX.d.o name to ftp.d.o. Sometimes, it'd be more appropriate to point it to a closer geographical mirror. (Say ftp.nz were performing maintenance, it'd be a lot more reasonable to send that traffic to Australia than to the Netherlands.) Is this impossible to fix/work around? No. However, it requires more thought and design than just slapping a few letsencrypt certs onto some hosts. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: When should we https our mirrors?
]] Aron Xu > To make it clear, content delivery systems used by pypi and npm don't > work for many people in China because: > > 1) Major global CDN providers don't have decent services in the > country (except akamai and cloudflare but need special contract); > > 2) BGP based network topology discovery never work because eBGP > routing is not widely deployed for subscriber network; While I sympatise with people in China who have less than stellar access to the entire internet, I don't think we should give the rest of the world a worse experience just so everybody has the same set of problems. At the same time, if we can design a solution that works well for everybody, that's of course preferable. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
