Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List

2023-07-29 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmozilla-publicsuffix-perl
  Version : 1.0.6
  Upstream Author : Tom Hukins 
* URL : https://metacpan.org/release/Mozilla-PublicSuffix
* License : MIT/X11
  Programming Lang: Perl
  Description : Perl interface to the Mozilla Public Suffix List

Mozilla::PublicSuffix provides a single function that returns the public
suffix of a domain name by referencing a parsed copy of Mozilla's Public
Suffix List. From the official website at https://publicsuffix.org/:

A "public suffix" is one under which Internet users can directly register names.
Some examples of public suffixes are com, co.uk and pvt.k12.wy.us. The Public
Suffix List is a list of all known public suffixes.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature


Bug#1024895: ITP: golang-github-bradenhilton-mozillainstallhash -- Go library to distinguish between Mozilla software installations

2022-11-27 Thread Ryan Kavanagh
Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
Control: block 1012721 by -1

* Package name: golang-github-bradenhilton-mozillainstallhash
  Version : 0.0~git20210630.c47e67d-1
  Upstream Author : Braden Hilton
* URL : https://github.com/bradenhilton/mozillainstallhash
* License : Expat
  Programming Lang: Go
Description: Go library to distinguish between Mozilla software installations
 This Go library retrieves from installs.ini and profiles.ini the hash used to
 differentiate between installations of Mozilla software.
-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature


Accepted mozilla-devscripts 0.54.2+nmu1 (source) into unstable

2022-08-22 Thread Debian FTP Masters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 15 Aug 2022 18:37:49 +0200
Source: mozilla-devscripts
Architecture: source
Version: 0.54.2+nmu1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Sebastian Ramacher 
Closes: 937085
Changes:
 mozilla-devscripts (0.54.2+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
 .
   [ Håvard F. Aasen ]
   * Finalize porting to Python 3. (Closes: #937085)
Checksums-Sha1:
 436d837168fe701f5d31eb45990f5438d4b19e1c 1754 
mozilla-devscripts_0.54.2+nmu1.dsc
 1011b5f2f1bd4914ca085d85f917fa841b4eb27c 42592 
mozilla-devscripts_0.54.2+nmu1.tar.xz
 1d4a03e48e34e1aa7cbe72209b1d0b49dd5e2972 7519 
mozilla-devscripts_0.54.2+nmu1_amd64.buildinfo
Checksums-Sha256:
 6cca44c5dfcb3a1b63759cba91fddf35420c6e28b81417d890885f75496ee3f6 1754 
mozilla-devscripts_0.54.2+nmu1.dsc
 09fbe9f0c41215193e1f96a0e0bef320d0374f98aee586b24069e743346abcfb 42592 
mozilla-devscripts_0.54.2+nmu1.tar.xz
 cadbb5a633993a820f6c12ad70ca6a46bc6c02e6ae41c37de2afff00df284fc2 7519 
mozilla-devscripts_0.54.2+nmu1_amd64.buildinfo
Files:
 6301016af736726ccdf7875d3ac92f43 1754 devel optional 
mozilla-devscripts_0.54.2+nmu1.dsc
 712e1ad9a47ae558615fb9d51bf6a738 42592 devel optional 
mozilla-devscripts_0.54.2+nmu1.tar.xz
 c8676c861b743149fe7aab3193b28561 7519 devel optional 
mozilla-devscripts_0.54.2+nmu1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE94y6B4F7sUmhHTOQafL8UW6nGZMFAmL6d4sACgkQafL8UW6n
GZOlMg//RIw/epajKe0isFKuUVW8TEthcJcdggqp/4/T78yzwVTedqXISaFKWEX6
YqGVgc+jZ8cQ62s000XWA/WiGOp1pPv1EvNmEgmrfuCbwj74bzGiJV5foeixEOL7
a+tzFjsn6qgPIQq7nbs4E5JTjtT3IsR2jXG8UPn+p/3LcTM2L3nnv59QrhOVKABF
8O9+rOUzsMBRLw2W/iCjZ0nFOnlx4nCoxv4i+yx3cDd3AbvJnf/6WkY1ddFNTTFZ
NPo136qHqDs9a34JLRngYV8/bALQzUd8kM7QoYfTLpr41YvqQAkrNsi19GuluhrB
8fJbsxQsZ7MhS2RAgrRv26n7grO+6y17VNYzOm73o4i85pOLx9nUd/Tvwkduvwaq
+74jR8aAhsr1r5S2JcpZGuQ6NR4fmVrppYDCWQQjcLq0JZqWF+cE01eqD/rsKQao
0cGcMoY9C1SJBKHRP7VIxGXTX6V7owyjC8i5EjYmRF+Wz9SMkGc++j6T0+9lYQC7
uek9s5vlFwg3YHxszXoOD081DJ0yq/PTBquokfSPXELXg+rXywbGUJggmOkOuilk
5jWlJQBFpALtpo2Dgqwfr9ujUnZUsYmMnP/cku1xNewkqd1usnMdDmYhL0BbWgLt
3tfITO+jVVqej9rmfm2DVxmgeJEwY4PPPk24P6baHrm56LDDwjQ=
=pbs5
-END PGP SIGNATURE-



Bug#990572: ITP: golang-mozilla-pkcs7 -- Go library for parsing and creating signed and enveloped messages

2021-07-02 Thread Peymaneh Nejad
Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-mozilla-pkcs7-dev
  Version : 0.0~git20200128.432b235-1
  Upstream Author : Mozilla Services
* URL : https://go.mozilla.org/pkcs7
* License : Expat
  Programming Lang: Go
  Description : Go library for parsing and creating signed and enveloped 
messages
 This package implements a subset of PKCS#7/Cryptographic Message Syntax
 (rfc2315, rfc5652) in Golang. It is a fork of github.com/fullsailor/pkcs7

This package is a dependency of github.com/smallstep/cli (#989857)



Accepted pkg-mozilla-archive-keyring 1.2+nmu1 (source) into unstable

2021-01-01 Thread Debian FTP Masters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 01 Jan 2021 16:47:23 +0100
Source: pkg-mozilla-archive-keyring
Architecture: source
Version: 1.2+nmu1
Distribution: unstable
Urgency: medium
Maintainer: Maintainers of Mozilla-related packages 

Changed-By: Holger Levsen 
Changes:
 pkg-mozilla-archive-keyring (1.2+nmu1) unstable; urgency=medium
 .
   * Non maintainer upload by the Reproducible Builds team.
   * No source change upload to rebuild on buildd with .buildinfo files.
Checksums-Sha1:
 79f4973dcc44698f863ba40c367a5a61f87067d8 1610 
pkg-mozilla-archive-keyring_1.2+nmu1.dsc
 6cedc36fa693a402fe36b0967aaea95c5375d2ee 3692 
pkg-mozilla-archive-keyring_1.2+nmu1.tar.xz
 fe34780a25cd8852bcbb6e3295704e52236a2b8f 6523 
pkg-mozilla-archive-keyring_1.2+nmu1_source.buildinfo
Checksums-Sha256:
 76c83f73a2346b97a6e1a96d222d920125fdd24180709f38a4d92057a4d5e79d 1610 
pkg-mozilla-archive-keyring_1.2+nmu1.dsc
 00e99c13d8455c325eee8c86f2fb9520e74e2ef447bec7251632eff9f76899ba 3692 
pkg-mozilla-archive-keyring_1.2+nmu1.tar.xz
 464dd360b1fc70d11e230b41a8b477ea49275579ce3fb001f062fc57bd7d8b94 6523 
pkg-mozilla-archive-keyring_1.2+nmu1_source.buildinfo
Files:
 f2cbc4962e8374697353f2f2a8e97309 1610 utils extra 
pkg-mozilla-archive-keyring_1.2+nmu1.dsc
 ce1f1db2c4625fccf9d3cf6b336fac89 3692 utils extra 
pkg-mozilla-archive-keyring_1.2+nmu1.tar.xz
 59e75d414d74847d91dbe12ff4d8f147 6523 utils extra 
pkg-mozilla-archive-keyring_1.2+nmu1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl/vRGAACgkQCRq4Vgaa
qhzLixAArIBmFSYIlaxgVlr3EUDO8MecIkfRHdD6JwSG/fQ6Gw12Rz1QRd5573GM
Eh7V1x32KjVQhbdg8UxHKgopcFA+kKnyi+SccJKV7YvS5hUjDO9Jy8o6MtJX8t+M
EfSKaNiadFDGWSN2FVFuyQhgyqrsebf35bg7iDqFNiw255HKYYBQ64A1HNPQz5cR
LKJxbl0ROLU1aOTHz7S46Bmc88P7hmF85X11vQJ/Sp7Xr9zITJT3yatpKI8OC0Sx
YpJv6JI8G4NCUxzazgcPJfjBj5tMAjFxLztMWNKn1CJzq8R06eN8/nj1Y3M/57OP
h3ufmqAiNdSpq55D32HD+9fhMRYRWPjo0vCj94xgxPUcsqKBcBNdoELz9JkkY8L/
Ytp4LuunxZRO/4xXCCMC8tQxCGA5gt3zyneuWjIgb47mVpHc1Z89Ut/dNyn/Kw4L
4tUgHeQ9D7CHXslMR0hH/ffPcihQcUR9YJa5ildGbLFX732TTMKOaT8qmNUPWt9W
zxz7yCxDWD72+nLAr1XEdk65ob+YtKB3TphfZNHNHV8g/mJXETCegcmUANpxLdOS
BAUeOo518AmBYhUa+KCrDNQVMgd7J/XMfAfLqaImK/otwZHDu6u55WR//8YRDK+U
5KZVL+iHPcU0/xtwPndUXDqb794v0ieBBnkf2YRN7P11reNwpDI=
=XgvQ
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.54.2 (source) into unstable

2020-08-31 Thread Debian FTP Masters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 31 Aug 2020 13:42:52 +0100
Source: mozilla-devscripts
Architecture: source
Version: 0.54.2
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Closes: 968841
Changes:
 mozilla-devscripts (0.54.2) unstable; urgency=medium
 .
   [ Simon McVittie ]
   * Change shebang on Python 2 scripts to #!/usr/bin/python2
 (Closes: #968841)
   * Use non-deprecated syntax for python-librdf dependency
   * Document the python-librdf change in the previous version
Checksums-Sha1:
 09c3561f54a72a4bb6e7e29452ade7004deee1f6 1177 mozilla-devscripts_0.54.2.dsc
 dbae9852118711bd6874fac159c9b83a982cb183 42436 mozilla-devscripts_0.54.2.tar.xz
 4ac2a175e039850786bf2d058f7dabaf501e1f60 6294 
mozilla-devscripts_0.54.2_source.buildinfo
Checksums-Sha256:
 8ef8c7bcc5171cfce2f92c76b83e82cab26804cadd047d5e316d84eba67f1f22 1177 
mozilla-devscripts_0.54.2.dsc
 56e35a5e8d39d73f7d9366116e951bef559067200f8d5518564b376f8e938258 42436 
mozilla-devscripts_0.54.2.tar.xz
 b1743e496f87cb07a8fb96021d446ba3668bbc7b3001f2f8f61ee8e5f0a30805 6294 
mozilla-devscripts_0.54.2_source.buildinfo
Files:
 f893afd662dc5840eb41e22bdcd5c232 1177 devel optional 
mozilla-devscripts_0.54.2.dsc
 d690a7690799ed4c464b474869471a57 42436 devel optional 
mozilla-devscripts_0.54.2.tar.xz
 56a9ca7e43d8b3d650e2a9dbfb48b464 6294 devel optional 
mozilla-devscripts_0.54.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCX0zwdQAKCRDrH8jaRfsp
MCHnAQCyXfQ2C2D8MsoELd91waVR+fqKpngJuBHb890kZPDt9wEArDmbJ+Qyw65M
Bt/cVFgSJxzMnPlj28uT+JfmRV7HJAM=
=bO+c
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.54.1 (source) into unstable

2020-08-08 Thread Debian FTP Masters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 08 Aug 2020 21:43:05 +0200
Source: mozilla-devscripts
Architecture: source
Version: 0.54.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Matthias Klose 
Closes: 967175
Changes:
 mozilla-devscripts (0.54.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * No-change upload to generate dependency on python2. Closes: #967175.
Checksums-Sha1:
 8be7d4a0f66c9564da7fe88fe0fc794e94557f71 1807 mozilla-devscripts_0.54.1.dsc
 5f302c0901b65e7a51c9ba84b00863ac8206d139 42376 mozilla-devscripts_0.54.1.tar.xz
 e43dde402322ea8e1add8a7687bfaeb0bfd7f090 6951 
mozilla-devscripts_0.54.1_source.buildinfo
Checksums-Sha256:
 af2660b398b41f4cbfb6724f2d475f89797c8bcf912158832b8848d0fc1815da 1807 
mozilla-devscripts_0.54.1.dsc
 39e80b2be956b087f00a64d1b7f5a82645a815bb3d823dbfc8110fae5c6a1c89 42376 
mozilla-devscripts_0.54.1.tar.xz
 168bd5860743aa0f540bdb34586ecf5548505ba4bae67b34bedfdb9e8ec39dc5 6951 
mozilla-devscripts_0.54.1_source.buildinfo
Files:
 7cd7a8583d7aacade4f20ff7ad45c368 1807 devel optional 
mozilla-devscripts_0.54.1.dsc
 a979a76b1c8d084b78d9cf538c0f446f 42376 devel optional 
mozilla-devscripts_0.54.1.tar.xz
 2831f45d43bfb8edc135e89a790cdf72 6951 devel optional 
mozilla-devscripts_0.54.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAl8vAhIQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9Zg7D/4p3MB6+374mKz4QlQW1PM2qTupTwIZx3yT
K1Yq3GQVq0vpnUdjnilRHuQMxbZ6g5GHPn0DUTfr1lhim1sZG4YXYNAA5h4qEne3
7xPohcUMZUMtwJDRT1quBSVPTSCP74Ig/IVxZe8FwTNhg5Ott+qWKd2nreQf/Qv9
efwmEM78fKQuGpRd5aGvnafSXkgkusifnk0NxNZl4lUSoiYH1WFiQKeuLEz2F9rn
p/CcgyIVIXeA1XFGZKXytvTpS5HHe1deVJNoM6ynWD0cCcCPAnoA8k5zR+bUCPU5
gBDRBVhvdqkUcbkG3C/DW+fuFXrQ+0Dzqnr7FGwgh69O+YewyTbn+tb1qDBRW8ns
p3Zfw5qeJjXH7o6/G7zIXD3U64Utoq8/K4Mr8YaxjahalZ6ZBGkwU6V1jzE0l+nC
uoH8WR0Q0R6mOp7F7MlqVugSXES3Ek6hCxYHzqTV84Q0j/LI1yQg4Xlo+h4jLxxk
6KX+XZiNChtTZmG/Dgr/7FPYpAsSM0gj5faFLQFVYkbxKKZdaI2ORISt/ZKQqfZe
ZrHVmLVjo4hbFAsJm0yy5rjODnIVFLEfiNtaISVsRTbSA7t8dwz5jzj1nxv68rsi
kQMj5IWK5S/EcjoBqm10kk3jaH8QZco+bsrMaACJrP5i1N0rxduBy6UhJTN6D9d1
hfICaRtntw==
=Bzh9
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.54 (source) into unstable

2019-11-03 Thread Benjamin Drung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 03 Nov 2019 22:43:29 +0100
Source: mozilla-devscripts
Architecture: source
Version: 0.54
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Benjamin Drung 
Closes: 827972 941112
Changes:
 mozilla-devscripts (0.54) unstable; urgency=medium
 .
   [ Olivier Tilloy ]
   * Fix dh_webext when there is a debian/install-webext file (Closes: #941112)
 .
   [ Benjamin Drung ]
   * Make pylint happier
   * dh_webext: Use logging
   * Port amo-changelog and xpi-repack to Python 3 (see Debian bug #937085)
   * Bump Standards-Version to 4.4.1 (no changes required)
   * Switch to debhelper 12
   * Remove Andrea Veri from uploaders. Thanks for your work. (Closes: #827972)
Checksums-Sha1:
 61a6ff2d549fd5f859f093fbc344e6787dbae439 1751 mozilla-devscripts_0.54.dsc
 98640b33633fe62c794963cbf2103fe8c755fabc 42324 mozilla-devscripts_0.54.tar.xz
 bc0f104443e06ddb7020d9445b815b62d8136ee5 8160 
mozilla-devscripts_0.54_source.buildinfo
Checksums-Sha256:
 2e38cb261d00669058c4a36204ef2f0ae8b21b392269832aff49ec2937e7bcfb 1751 
mozilla-devscripts_0.54.dsc
 1d536ed510054da3bfb2f1be7ec5931ed1f1d807bb4bb857e916a9daff4f376a 42324 
mozilla-devscripts_0.54.tar.xz
 614d7f6930b0230c03e461627e8f7d6ef3c62e125fe0a987d0117e241605796a 8160 
mozilla-devscripts_0.54_source.buildinfo
Files:
 ef6643fa9e02cdf4296a782da500e39c 1751 devel optional 
mozilla-devscripts_0.54.dsc
 b7ea0b6f99cabc4709c6c459bc120b07 42324 devel optional 
mozilla-devscripts_0.54.tar.xz
 8271dcbe364928c1ed411f3f84390c97 8160 devel optional 
mozilla-devscripts_0.54_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpi0s+9ULm1vzYNVLFZ61xO/Id0wFAl2/SrkACgkQFZ61xO/I
d0yHJQ/9G5KYYUWEVAVXBKDLPUr0fbsgQt2ushsSTXoNhLfj2R/4ZvRE+mh1xQGs
t7fYsBJQPbugNteF54eDSLfKmxlCLBCf7wCdo5OHKTkiymiVCQieM0evNz72AYWz
DNGu2QyesOyTbH/3cFJixUDCszajUXuOYrYDl3c8HGpruDu1buQUy5a38Z/Qkm3W
bs144AwC5RevfzTkNnXbapy4Ed2poEF2VRRXNWMNMJH84F2L/XXsZfwKmdqbgTkJ
VntdAqCehPprjebZlP1kLbShooSvSIm2j8Si0PKqdJ2g6NDETCqbSsAcI+oTNsEx
thlcjwdKz8Tho4gCoBJFVuER4dR9BlfVMteiSu+K2MSfm0c6u8Wwf0lihPn4Vj2a
nFjeYk4gYJDU25qgDhY+3QgAQCmbkqx7xwCD/gKi79Sb50lwnmtwj1TwlHRUqvoj
NU13/MsObQeQvTvOl+VkJ6/mgKEOgGuFJhLgJXI2YWbBBAEmU0dP4nZlNp+OB3+E
oHY8J0cmbYmcjOLF+AdVMeRi4daiAjG8FLmhyDnDclgq5lOmUxc/9gnTMOS8eMa1
luE3vJEsHc91s2vHCXYGayEsj/fepfqZJewH6XD5ozPuPt/wpR01La6JoZakzY8w
DdKsvBthQZOTxLNGa5pP6JtIEx07tOhdoY+0ENAUXbhyBXIAQEo=
=8SL/
-END PGP SIGNATURE-



Suggestion: You should delete Mozilla ESR programs

2019-10-30 Thread patrick . dreier



Dear Woman and Man!

Suggestion: You should delete Mozilla ESR programs otherwise you have
double work for programming, testing.
You should leave more time for the normal version.
http://ftp.mozilla.org/pub/firefox/releases/52.0.2/linux-x86_64/en-US/

With kind Greetings!



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-28 Thread Ross Vandegrift
On Sat, Sep 28, 2019 at 01:17:14AM -0400, Nicholas D Steeves wrote:
> Florian Weimer  writes:
> > Cloudflare only promises to “never sell your data”.  That doesn't
> > exclude sharing it for free with interested parties.
> >
> 
> So a metadata leak (by design) to an unbounded number of entities,
> affecting all Firefox users, at a time when this data is gold?

No, that is incorrect.  The full text says "CloudFlare will not sell, license,
sublicense, or grant any rights to your data that we collect from DNS queries
to any other person or entity without your consent."  This doesn't cover
APNIC's research, that's described separately.  You may dislike CloudFlare and
APNIC having the data at all - but the entities seem clearly bounded.

In case this isn't well-known: in the US residential ISP market, this privacy
policy is *far* better than anything else on offer.  They commonly give ISPs
much more latitute for abuse.  SiteFinder-style DNS hijacking is widespread,
and often cannot be disabled.  "Contracts" with ISPs are one-sided: they
absolve providers of any liability and force customers to preemptively waive
their rights to legal action.  This is probably the backdrop that Mozilla has
in mind.

But of course US residential internet access isn't the whole world.  The
commercial ISP market in the US is more reasonable.  And maybe residential
broadband is better off elsewhere in the world?

Ross


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-28 Thread Bastian Blank
On Sat, Sep 28, 2019 at 11:02:30AM +0200, Philipp Kern wrote:
> > 
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Those two have one critical difference in what they actually log:

"Cloudflare Resolver IP address + Destination Port"
vs.
"Resolver IP address + Port the Query Originated From"

So the first form only logs the AS the query originated from, the later
logs the IP it comes from.

Bastian

-- 
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-28 Thread Florian Weimer
* Philipp Kern:

> It is probably worth pointing out that Firefox's use of Cloudflare's DoH
> endpoint is governed by a different policy outlined here:
>
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Thanks.

> Per that policy, other third parties can only get the data with
> Mozilla's written permissions. And APNIC (or any other third party) is
> not mentioned.

But isn't that policy less restrictive that the other, once Mozilla
has given permission?



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-28 Thread Philipp Kern
On 9/27/2019 12:23 PM, Florian Weimer wrote:
[...]>> So currently DoH is strictly worse.
> 
> Furthermore, you don't have a paid contract with Cloudflare, but you
> usually have one with the ISP that runs the recursive DNS resolver.
> 
> If you look at 
> 
>   
> 
> you will see that the data is shared with APNIC for “research”:
> 
> | Under the terms of a cooperative agreement, APNIC will have limited
> | access to query the transaction data for the purpose of conducting
> | research related to the operation of the DNS system.
> 
> And:
> 
> | Specifically, APNIC will be permitted to access query names, query
> | types, resolver location
> 
> 
> 
> Typically, APNIC will only see a subset of the queries if you use your
> ISP's DNS resolver (or run your own recursive resolver).
> 
> Cloudflare only promises to “never sell your data”.  That doesn't
> exclude sharing it for free with interested parties.
It is probably worth pointing out that Firefox's use of Cloudflare's DoH
endpoint is governed by a different policy outlined here:

https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Per that policy, other third parties can only get the data with
Mozilla's written permissions. And APNIC (or any other third party) is
not mentioned.

Kind regards
Philipp Kern



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-27 Thread Nicholas D Steeves
Wouter Verhelst  writes:

> On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
>> On Sep 08, Ondřej Surý  wrote:
>> 
>> > I would rather see an explicit statement. I would be very surprised 
>> > with Debian’s usual stance regarding the users’ privacy that we would 
>> > not consider this as a privacy violation, but again I am not Firefox 
>> > maintainer in Debian and I would rather hear from them than speculate 
>> > on my own.
>> I think that this is a privacy enhancement, since it prevents some major 
>> ISPs from spying on users DNS queries.
>
[snip]
>> It would be a terrible signal if Debian decided to disable an 
>> anti-censoship feature provided by an upstream vendor.
>
> Except DoH is *not* an anti-censorship feature. It is a feature that
> provides a net reduction in privacy.
>
> CloudFlare says that it won't read your DNS requests -- scout's honour!
> -- but even if that's true and we can believe it, there's no reason to
> assume it will continue to do so forever, past any potential future
> acquisitions or CEO changes.
>
> Mozilla really missed the ball on this one. OpenBSD already made the
> necessary changes to Firefox. I think we should, too.
>

+1 !

Especially because

Florian Weimer  writes:

> If you look at 
>
>   <https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/>
>
> you will see that the data is shared with APNIC for “research”:
>
> | Under the terms of a cooperative agreement, APNIC will have limited
> | access to query the transaction data for the purpose of conducting
> | research related to the operation of the DNS system.
>
> And:
>
> | Specifically, APNIC will be permitted to access query names, query
> | types, resolver location
>
> <https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/privacy-policy/>
>
> Typically, APNIC will only see a subset of the queries if you use your
> ISP's DNS resolver (or run your own recursive resolver).
>
> Cloudflare only promises to “never sell your data”.  That doesn't
> exclude sharing it for free with interested parties.
>

So a metadata leak (by design) to an unbounded number of entities,
affecting all Firefox users, at a time when this data is gold?

How is this not as bad or worse than GAFA?


Regards,
Nicholas


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-27 Thread Bjørn Mork
Robert Edmonds  writes:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.

Running a local root instance is possible and easy.  See
https://tools.ietf.org/html/rfc7706


Bjørn



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-27 Thread Florian Weimer
* Robert Edmonds:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.
>
> There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
> number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
> of bandwidth required by a query/response pair of UDP DNS packets to
> obtain the delegation for a TLD.

Or you can turn on query minimization and NSEC-based NXDOMAIN
synthesis, at which point there is hardly any privacy leak left.

The challenge with the root zone is that anyone can become a de-facto
root server operator for their own part of the Internet (at least with
physical control over machines), by inviting some of the established
operators to host an anycast node on their network.  It's very
difficult to guarantee privacy in such a widely distributed system.



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-27 Thread Florian Weimer
* Adam Borowski:

> Let's compare; by "ISP" I mean every hop on the network path.
>
> With local DNS:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the DNS packets, reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking DNS packets, blocking actual connection]
> * DNSSEC forbids falsifying DNS
>
> With DoH:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking actual connection]
> * Cloudflare can read the destination of every connection
>   [they serve the DNS...]
> * Cloudflare can falsify DNS¹
> * Cloudflare can block connections
>   [blocking or falsifying DNS response]
>
> So currently DoH is strictly worse.

Furthermore, you don't have a paid contract with Cloudflare, but you
usually have one with the ISP that runs the recursive DNS resolver.

If you look at 

  

you will see that the data is shared with APNIC for “research”:

| Under the terms of a cooperative agreement, APNIC will have limited
| access to query the transaction data for the purpose of conducting
| research related to the operation of the DNS system.

And:

| Specifically, APNIC will be permitted to access query names, query
| types, resolver location



Typically, APNIC will only see a subset of the queries if you use your
ISP's DNS resolver (or run your own recursive resolver).

Cloudflare only promises to “never sell your data”.  That doesn't
exclude sharing it for free with interested parties.

(Some people may find it amusing that I'm concerned by this because I
opened that particular can of worms fifteen years ago.)



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-15 Thread Amir H. Firouzian
Debian doesn't add ESNI Record into it's Name Server.

Check here (ONLINE dig):
https://toolbox.googleapps.com/apps/dig/#TXT/

Check these two domains:
_esni.debian.org
_esni.cloudflare.com

On Sun, Sep 15, 2019 at 5:31 AM Paul Wise  wrote:
>
> On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> > On 9/13/19 7:05 AM, Simon Richter wrote:
> > >
> > > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > > circumvented easily.
> > >
> > > This is a game that we should not play, really. It raises the cost of
> > > running a service on the Internet so only big players can afford to do so.
> >
> > Does it? I haven't personally deployed it yet anywhere, but when I
> > briefly looked into it, it appears to require adding a DNS record & some
> > web server config. If anything, it appears to be harder to do if you're
> > a big player (e.g., making sure your DNS servers always return matching
> > ESNI and A/ records, even when you have geo-targeted DNS — so much
> > easier when you only have one server.)
>
> Does anyone know if any software in Debian supports ESNI records?
>
> Looking at the RFC draft, it sounds like adding ESNI records to
> debian.org would basically duplicate the DANE records debian.org
> already has. sigh
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
> https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-14 Thread Paul Wise
On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> On 9/13/19 7:05 AM, Simon Richter wrote:
> >
> > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > circumvented easily.
> >
> > This is a game that we should not play, really. It raises the cost of
> > running a service on the Internet so only big players can afford to do so.
>
> Does it? I haven't personally deployed it yet anywhere, but when I
> briefly looked into it, it appears to require adding a DNS record & some
> web server config. If anything, it appears to be harder to do if you're
> a big player (e.g., making sure your DNS servers always return matching
> ESNI and A/ records, even when you have geo-targeted DNS — so much
> easier when you only have one server.)

Does anyone know if any software in Debian supports ESNI records?

Looking at the RFC draft, it sounds like adding ESNI records to
debian.org would basically duplicate the DANE records debian.org
already has. sigh

https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-14 Thread Anthony DeRobertis

On 9/13/19 7:05 AM, Simon Richter wrote:


Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.


Does it? I haven't personally deployed it yet anywhere, but when I 
briefly looked into it, it appears to require adding a DNS record & some 
web server config. If anything, it appears to be harder to do if you're 
a big player (e.g., making sure your DNS servers always return matching 
ESNI and A/ records, even when you have geo-targeted DNS — so much 
easier when you only have one server.)




Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-14 Thread Amir H. Firouzian
Becuase the best privacy solution would be to embed DNS resolver into
mozilla and they query root servers (which manage by ICANN) to find
IPs of TLDs server!
I mean the "users’ privacy" is a opaque general definition, rather
there are the spectrum of techniques which protect us against mass
surveillance. So in some sense there is violation and in other
condition it could be protector (ISP don't realize the packet DNS
QUERY ONLY). There is a trade of as always :)

On Thu, Sep 12, 2019 at 10:28 PM Ondřej Surý  wrote:
>
> What? How did you manage to go from me suggesting disabling DoH by default to 
> CloudFlare in Firefox without explicit user consent to an attack on ICANN?
>
> But I guess that this alternative DNS root nonsense will just never die, so I 
> should not be really surprised.
>
> --
> Ondřej Surý 
>
> > On 12 Sep 2019, at 19:45, Amir H. Firouzian  wrote:
> >
> > Then you should ask why we have ICANN in the first place!
> >
> > PS: https://en.wikipedia.org/wiki/OpenNIC
> >
> >> On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
> >>
> >> Hi,
> >>
> >> I haven’t found any discussion on the topic (although I haven’t searched 
> >> very hard and only looked for DoH and DNS keywords in the BTS), but since 
> >> Mozilla plans to enable DoH to CloudFlare by default to US based users: 
> >> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
> >>  I would rather see an explicit statement. I would be very surprised with 
> >> Debian’s usual stance regarding the users’ privacy that we would not 
> >> consider this as a privacy violation, but again I am not Firefox 
> >> maintainer in Debian and I would rather hear from them than speculate on 
> >> my own.
> >>
> >> Thanks,
> >> Ondřej
> >> --
> >> Ondřej Surý 



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Shengjing Zhu
On Sat, Sep 14, 2019 at 12:25 PM Shengjing Zhu  wrote:
> It's too native have such thoughts. It's never "too big to block".

s/native/naive/

-- 
Shengjing Zhu



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Shengjing Zhu
On Fri, Sep 13, 2019 at 7:05 PM Simon Richter  wrote:
>
> Hi,
>
> On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:
>
> > > Note that by way of counterargument, Google and its services have
> > > been blocked in mainland China by the Great Firewall for nearly a
> > > decade now, so I question whether there is really such a thing as
> > > "too big to block."
>
> > This is a false dichotomy: not all nation states are willing to go to
> > the extreme lengths as China.
>
> Also, China cannot block Github, because they have no equivalent, and even
> if they did, it wouldn't have the same content. Google is too easily
> replicated, because they have no immediate contributors.
>
> I expect that China will set up a proxy service with clones of all relevant
> Github repositories soon to keep read-only access to free software around
> but inhibit organizing through shared documents.
>
> CloudFlare has too many services behind them that are important for the
> economy and not replicable, so they are in a better position than Github
> here.
>

Really?

It's too native have such thoughts. It's never "too big to block".
It's "not worth to block" if it's not too big. If you are in the
"real" censorship environment, you would know how meaningless it is to
rely on some "big" third-partys.

Please don't in name of censorship-resistant.

-- 
Shengjing Zhu



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Roger Lynn

On 09/09/19 14:40, Bjørn Mork wrote:

Ondřej Surý  writes:

Otherwise it doesn’t make any sense to remove external links to logos
and JavaScript from the documentation and then send everything to one
single US-based provider.


Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


It apparently already does, although they appear to be used only under 
certain circumstances. See https://bugs.debian.org/761658


Roger



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Sam Hartman
>>>>> "Holger" == Holger Levsen  writes:

>> Mozilla really missed the ball on this one. OpenBSD already made
>> the necessary changes to Firefox. I think we should, too.

Holger> agreed.

OK, so, it seems like the way we do things, that's going to be the
firefox maintainer's decision.

I think right now this discussion is drifting away from being
productive.  There's not a clear consensus and people are starting to
repeat each other.
It could be useful if any of a number of things are happen:

* The firefox maintainers pop up and say it is useful to them.  For
  example if they are trying to get additional input to make a
  decision.  (My assumption is that the firefox maintainers have not
  been particularly active in this discussion.  If so, my entire basis
  for this message may be wrong.  In a different worldh I would go check
  and see who all the active firefox maintainers were and see if they
  have been active)

* Someone volunteers to write up the arguments made here as part of a
  bug requesting either no change or some change.  Obviously such a bug
  could point to this discussion and better yet summarize the arguments
  made.

--Sam



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Evilham

On dv., set. 13 2019, Simon Richter wrote:


Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> Note that by way of counterargument, Google and its services 
> have
> been blocked in mainland China by the Great Firewall for 
> nearly a
> decade now, so I question whether there is really such a 
> thing as

> "too big to block."


This is a false dichotomy: not all nation states are willing to 
go to

the extreme lengths as China.


Also, China cannot block Github, because they have no 
equivalent, and even
if they did, it wouldn't have the same content. Google is too 
easily

replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of 
all relevant
Github repositories soon to keep read-only access to free 
software around

but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important 
for the
economy and not replicable, so they are in a better position 
than Github

here.

Also, this is a cat and mouse game and DoH is probably just the 
next

step :encrypted SNI will probably be needed as well later.


Mandatory Encrypted SNI with no fallback option -- everything 
else can be

circumvented easily.

This is a game that we should not play, really. It raises the 
cost of
running a service on the Internet so only big players can afford 
to do so.


We are throwing some ice cubes into the boiling pot so there are 
local
zones that are warming up slow enough that the frogs there do 
not notice.

This is a losing strategy.

   Simon



There's also this:
 https://use-application-dns.net/
 https://tools.ietf.org/html/draft-grover-add-policy-detection-00

The way I read it, it means that "soon" DoH would be enabled by 
default for "everyone" unless it can be trivially disabled by the 
network operator.


Quite confusing, at least for me it'd look as having all the 
issues of centralising DNS (a couple kill-switches for de-facto 
global censorship) and then undoing all the benefits of using 
encrypted DNS in the first place.

--
Evilham



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Holger Levsen
On Thu, Sep 12, 2019 at 11:02:22PM +0200, Wouter Verhelst wrote:
> Except DoH is *not* an anti-censorship feature. It is a feature that
> provides a net reduction in privacy.

agreed.

> CloudFlare says that it won't read your DNS requests -- scout's honour!
> -- but even if that's true and we can believe it, there's no reason to
> assume it will continue to do so forever, past any potential future
> acquisitions or CEO changes.

exactly.

> Mozilla really missed the ball on this one. OpenBSD already made the
> necessary changes to Firefox. I think we should, too.

agreed.

so, iceweasel again? :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Marco d'Itri
On Sep 13, Ondřej Surý  wrote:

> > We are talking about preventing large scale censorship (I do not think 
> > that this is really about privacy) for *general users*: obviously *we* 
> > already know about countless workarounds.
> That’s a false statement. Right now, we are talking about sending _all_ your 
> queries from
> just **one** application - Mozilla Firefox.  And what’s worse - if we are 
> talking about protecting
> the users, it could lead to a false sense of protection - any other 
> application in the system
> will send the DNS queries through stub resolver (e.g. most probably to 
> whatever the system
> gets from the DHCP).
I have never argued for or against "protecting users": the problem 
I care about is DNS-based censorship of web sites and DoH from the 
browser to a third party resolver solves this, at least for the time 
being.

> BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is 
> on the list of
I have seen it: it is an interesting list of companies selling 
DNS-related products or services, USA ISPs who are highly suspect in 
their sudden interest in their customers' privacy and of UK ISPs that 
I assume are subject to regulatory pressure.

> participants from the very beginning.  There’s no doubt that we need to 
> encrypt DNS, but
> in a way that won’t lead to every app sending it’s DNS queries to a different 
> resolver.
This would be nice: maybe a few of these large companies would like to 
fund adding DoH support to systemd-resolved?

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Simon Richter
Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> > Note that by way of counterargument, Google and its services have
> > been blocked in mainland China by the Great Firewall for nearly a
> > decade now, so I question whether there is really such a thing as
> > "too big to block."

> This is a false dichotomy: not all nation states are willing to go to 
> the extreme lengths as China.

Also, China cannot block Github, because they have no equivalent, and even
if they did, it wouldn't have the same content. Google is too easily
replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of all relevant
Github repositories soon to keep read-only access to free software around
but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important for the
economy and not replicable, so they are in a better position than Github
here.

> Also, this is a cat and mouse game and DoH is probably just the next 
> step :encrypted SNI will probably be needed as well later.

Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.

We are throwing some ice cubes into the boiling pot so there are local
zones that are warming up slow enough that the frogs there do not notice.
This is a losing strategy.

   Simon



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Ondřej Surý
> On 13 Sep 2019, at 12:25, Marco d'Itri  wrote:
> 
> We are talking about preventing large scale censorship (I do not think 
> that this is really about privacy) for *general users*: obviously *we* 
> already know about countless workarounds.

That’s a false statement. Right now, we are talking about sending _all_ your 
queries from
just **one** application - Mozilla Firefox.  And what’s worse - if we are 
talking about protecting
the users, it could lead to a false sense of protection - any other application 
in the system
will send the DNS queries through stub resolver (e.g. most probably to whatever 
the system
gets from the DHCP).

Again, please note, I am not advocating against DoH or DoT, I just think we 
need to do
a better job to protect our users than blindly following Mozilla’s lead by 
enabling it by default
without explicit user consent.

BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is on 
the list of
participants from the very beginning.  There’s no doubt that we need to encrypt 
DNS, but
in a way that won’t lead to every app sending it’s DNS queries to a different 
resolver.

Ondrej
--
Ondřej Surý
ond...@sury.org



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Marco d'Itri
On Sep 13, Jeremy Stanley  wrote:

> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
This is a false dichotomy: not all nation states are willing to go to 
the extreme lengths as China.
Also, this is a cat and mouse game and DoH is probably just the next 
step :encrypted SNI will probably be needed as well later.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Marco d'Itri
On Sep 13, Thomas Goirand  wrote:

> You shouldn't insist on always writing "their ISP", as if it was the
> only choice. It isn't. One can setup his own recursive DNS locally, for
> example. I've done this for years, as I didn't trust my ISP (first, in
Sure, me too: but it does not matter, because if somebody knows how to 
setup a local resolver then they surely can change a browser setting as 
well.
We are talking about preventing large scale censorship (I do not think 
that this is really about privacy) for *general users*: obviously *we* 
already know about countless workarounds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-13 Thread Thomas Goirand
On 9/10/19 7:46 PM, Marco d'Itri wrote:
> You obviously consider Mozilla's choices of trusted resolvers (currently 
> Cloudflare, hopefully others too in the future) a bigger privacy risk 
> for generic users (the one who use the browser defaults) than their ISP, 
> I disagree.

You shouldn't insist on always writing "their ISP", as if it was the
only choice. It isn't. One can setup his own recursive DNS locally, for
example. I've done this for years, as I didn't trust my ISP (first, in
China, now I don't trust here in Europe either).

Thomas



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Shengjing Zhu
// send from my mobile device

Jeremy Stanley  于 2019年9月13日周五 06:51写道:

> On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote:
> [...]
> > The idea for resilience is "too big to block".
> >
> > When Domain Fronting still worked with Google, people used this to
> > circumvent censorship because blocking it would have required
> > blocking Google, so cooperation from Google was necessary to
> > implement effective censorship.
> [...]
> > I'd be in favour of installing it by default (keep in mind: we are
> > also "too big to block", so we're in the position to give software
> > that is useful for activists an install base that makes it hard to
> > identify activists by having the software installed).
>
> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
> --
> Jeremy Stanley
>

I share the same concern. And please note that cloudflare doesn't have pop
in China mainland, and in some ISP from China, the latency can be more than
200ms(http://mping.chinaz.com/?host=1.0.0.1).

>


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Jeremy Stanley
On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote:
[...]
> The idea for resilience is "too big to block".
> 
> When Domain Fronting still worked with Google, people used this to
> circumvent censorship because blocking it would have required
> blocking Google, so cooperation from Google was necessary to
> implement effective censorship.
[...]
> I'd be in favour of installing it by default (keep in mind: we are
> also "too big to block", so we're in the position to give software
> that is useful for activists an install base that makes it hard to
> identify activists by having the software installed).

Note that by way of counterargument, Google and its services have
been blocked in mainland China by the Great Firewall for nearly a
decade now, so I question whether there is really such a thing as
"too big to block."
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Wouter Verhelst
On Thu, Sep 12, 2019 at 11:43:33PM +0200, Marco d'Itri wrote:
> On Sep 12, Wouter Verhelst  wrote:
> 
> > Except all they need to do is return NXDOMAIN on the
> > "use-application-dns.net" domain, and Presto! they can spy on their
> > users again.
> They need to have a government to compel then to do it, which is not 
> obvious.

That's not in the announcement. In fact, it also allows for "opt-in
parental controls", which has nothing to do with governments.

> And then Mozilla will disable that (you can read this clearly 
> in their announcement) and figure out a different strategy.

The announcement does indeed mention that, yes. I sincerely doubt
they'll actually do that, though, unless more than, say, 50% of the
networks they measure end up disabling things.

Of course that's just a matter of personal opinion.

> > Meanwhile, Firefox' default sends everything to the other side of the
> > Internet without the user's consent. How does that improve privacy?
> Not really "to the other side": Cloudflare's resolvers are highly 
> anycasted.

I admit to using some hyperbole here, but the point was that your data
is being sent to a partner of the software you happen to be using,
without you having a contractual relationship with them.

If your bank did that, you'd yell that it's improper. So why is a
browser allowed to do so?

Don't get me wrong; I applaud Mozilla for trying to make encrypted DNS
the default. I just don't think they're going about it the right way.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Marco d'Itri
On Sep 12, Wouter Verhelst  wrote:

> Except all they need to do is return NXDOMAIN on the
> "use-application-dns.net" domain, and Presto! they can spy on their
> users again.
They need to have a government to compel then to do it, which is not 
obvious. And then Mozilla will disable that (you can read this clearly 
in their announcement) and figure out a different strategy.

> Meanwhile, Firefox' default sends everything to the other side of the
> Internet without the user's consent. How does that improve privacy?
Not really "to the other side": Cloudflare's resolvers are highly 
anycasted.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Wouter Verhelst
On Tue, Sep 10, 2019 at 07:56:48PM +0200, Julien Cristau wrote:
> On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote:
> 
> > > On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> > > 
> > > I for one, do trust my ISPs a lot more than I trust Cloudflare or
> > > Google, simply based on the jurisdiction.
> > 
> > While I still strongly agree with you on this one (even though I think all
> > major ISPs here are scumbags, especially the incumbent), I still strongly
> > think we should not have this debate here, and we should turn this around
> > the usual Debian policy - to not send data to 3rd party without explicit 
> > user
> > content and defaulting to not doing so.
> > 
> How is this worse than what we're already doing by default, namely
> sending the same data to whoever happens to be on the network, in
> addition to whoever happened to be listed in an unauthenticated dhcp
> response?  (Which, if you're lucky, is your ISP, aka a 3rd party.)

The major difference is that third party is someone you've got a
contractual relation with.

If you're talking to CloudFlare, you don't. Good luck calling CloudFlare
support when something goes wrong.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Wouter Verhelst
On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
> On Sep 08, Ondřej Surý  wrote:
> 
> > I would rather see an explicit statement. I would be very surprised 
> > with Debian’s usual stance regarding the users’ privacy that we would 
> > not consider this as a privacy violation, but again I am not Firefox 
> > maintainer in Debian and I would rather hear from them than speculate 
> > on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries.

Except all they need to do is return NXDOMAIN on the
"use-application-dns.net" domain, and Presto! they can spy on their
users again.

https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https

So no, DoH defeats people who run wireshark, but it does not "prevent
some major ISPs from spying". If a "major ISP" wants to spy, it just
needs to tell Firefox "hey, that DoH feature? Please just disable it,"
and it's back in business.

Meanwhile, Firefox' default sends everything to the other side of the
Internet without the user's consent. How does that improve privacy?

> When it will be enabled in other countries it will prevent
> government-mandated (or "encouraged") censorship.

Nope. See above.

> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.

Except DoH is *not* an anti-censorship feature. It is a feature that
provides a net reduction in privacy.

CloudFlare says that it won't read your DNS requests -- scout's honour!
-- but even if that's true and we can believe it, there's no reason to
assume it will continue to do so forever, past any potential future
acquisitions or CEO changes.

Mozilla really missed the ball on this one. OpenBSD already made the
necessary changes to Firefox. I think we should, too.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Simon Richter
Hi,

On Thu, Sep 12, 2019 at 06:52:47PM +0200, Adam Borowski wrote:

> > I still believe that generic users are better served by deploying more 
> > censorship-resistant protocols than by worrying that Cloudflare (or 
> > whoever else) would violate the privacy requirements mandated by 
> > Mozilla.

> Sure, but DoH is less censorship-resistant not more.

The idea for resilience is "too big to block".

When Domain Fronting still worked with Google, people used this to
circumvent censorship because blocking it would have required blocking
Google, so cooperation from Google was necessary to implement effective
censorship.

For the same reason, a lot of political activism is taking place on Github,
who have a smaller target market than Google and have fewer staff exposed
in hostile political environments, so they can manage threats by
restricting employees' travel.

The same will apply to services also hosted on a big CDN, and I believe
that is the business model behind providing this service in the first
place -- pull international activists onto CloudFlare.

I expect this to bring a marked improvement for a short time, followed by
the realization at CF that they exist by the kind permission of
nation-state actors that are very interested in strategic Internet choke
points.

To put it bluntly: CloudFlare has, as a consequence of their business
model, too many employees and assets bound in various jurisdictions. Their
censorship resilience is going to be limited to countries where they do not
have a local presence.

They already need to be able to return different results depending on the
client's IP address, otherwise they break anycast or split horizon based
load balancing for everyone whose DNS they do not control themselves. This
mechanism will be used to limit the scope of governmental censorship
requests to the appropriate geographic area.

To be honest, my feeling is that CloudFlare management are not believing
this to be political at all -- it's a technical solution that improves
service for their own customers and degrades service for non-customers
(because it breaks traditional geo-based load balancing), so of course they
are going to do this.

They have a history of ignoring context, and the fallout will be
interesting to watch. In the meantime, we have a responsibility towards our
users to not expose them to unnecessary risks.

I'm fairly sure that a plugin to control the DoH setting from the
navigation bar will pop up shortly. I'd be in favour of installing it by
default (keep in mind: we are also "too big to block", so we're in the
position to give software that is useful for activists an install base that
makes it hard to identify activists by having the software installed).

   Simon



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Clément Hermann
Le September 12, 2019 4:52:47 PM UTC, Adam Borowski  a 
écrit :
>On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
>> On Sep 09, Adam Borowski  wrote:
>> 
>> > With DoH:
>> > * the target server knows about you (duh!)
>> > * the ISP can read the destination of every connection
>> >   [reading the IP header, reading SNI header]
>> > * the ISP can block such connections
>> >   [blocking actual connection]
>> Well, no. They cannot without significantly more expensive hardware
>to 
>> do DPI and a *totally different* legislative framework.
>> (Source: I have been dealing with government-mandated censorship in 
>> Italy for ~15 years, both at technical and policy levels.)
>
>I don't understand how blocking by IP would be any more expensive than
>blocking by DNS.  It's _cheaper_: you read a field in the IP header
>instead
>of doing it in a higher level DNS server.

I don't think it is, actually. Disregarding the legal framework part, only 
looking at the technical aspect of things, when you do it with DNS, you just 
have to create a local version of the zone that has be censored and distribute 
it normally on your resolvers, for instance. 

Anyway you do a high level modification in a high level service. Request will 
go through your DNS infrastructure the way it's intended to.

However, reading IP headers on routers to block a particular destination is not 
how network are designed to operate. It's not as cheap a function you'd think, 
because it means either being able on the customer router, or close to it, and 
those aren't usually designed to filter that way, or you make sure all traffic 
pass by a filtering router at some point - which means dedicated hardware with 
the traffic load involved. This is usually complicated in a large ISP context: 
networks are huge and evolved over time ; and they weren't designed for 
censorship to begin with, there was this thing called Net Neutrality... ;)

Cheers,

-- 
nodens



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Ondřej Surý
What? How did you manage to go from me suggesting disabling DoH by default to 
CloudFlare in Firefox without explicit user consent to an attack on ICANN?

But I guess that this alternative DNS root nonsense will just never die, so I 
should not be really surprised.

--
Ondřej Surý 

> On 12 Sep 2019, at 19:45, Amir H. Firouzian  wrote:
> 
> Then you should ask why we have ICANN in the first place!
> 
> PS: https://en.wikipedia.org/wiki/OpenNIC
> 
>> On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
>> 
>> Hi,
>> 
>> I haven’t found any discussion on the topic (although I haven’t searched 
>> very hard and only looked for DoH and DNS keywords in the BTS), but since 
>> Mozilla plans to enable DoH to CloudFlare by default to US based users: 
>> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
>>  I would rather see an explicit statement. I would be very surprised with 
>> Debian’s usual stance regarding the users’ privacy that we would not 
>> consider this as a privacy violation, but again I am not Firefox maintainer 
>> in Debian and I would rather hear from them than speculate on my own.
>> 
>> Thanks,
>> Ondřej
>> --
>> Ondřej Surý 



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Amir H. Firouzian
Then you should ask why we have ICANN in the first place!

PS: https://en.wikipedia.org/wiki/OpenNIC

On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý  wrote:
>
> Hi,
>
> I haven’t found any discussion on the topic (although I haven’t searched very 
> hard and only looked for DoH and DNS keywords in the BTS), but since Mozilla 
> plans to enable DoH to CloudFlare by default to US based users: 
> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
>  I would rather see an explicit statement. I would be very surprised with 
> Debian’s usual stance regarding the users’ privacy that we would not consider 
> this as a privacy violation, but again I am not Firefox maintainer in Debian 
> and I would rather hear from them than speculate on my own.
>
> Thanks,
> Ondřej
> --
> Ondřej Surý 



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Bastian Blank
On Thu, Sep 12, 2019 at 06:26:34PM +0200, Marc Haber wrote:
> Will DOH break corporate web apps that are accessed over a VPN (and
> thus only resolvable via the local resolver)? Or has Mozilla catered
> for that?

Please see https://wiki.mozilla.org/Trusted_Recursive_Resolver.
network.trr.mode=2 seems to configure what you want.  DoH needs to be
able to bootstrap anyway.

Bastian

-- 
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
   stardate 5928.5.



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Ansgar
Adam Borowski writes:
> On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
>> Well, no. They cannot without significantly more expensive hardware to 
>> do DPI and a *totally different* legislative framework.
>> (Source: I have been dealing with government-mandated censorship in 
>> Italy for ~15 years, both at technical and policy levels.)
>
> I don't understand how blocking by IP would be any more expensive than
> blocking by DNS.  It's _cheaper_: you read a field in the IP header instead
> of doing it in a higher level DNS server.

>From the top of my head I can think of several reasons:

 - For IP-level blocking you need to implement blocking in more places
   instead of a central place (DNS); also more data needs to be
   processed in total.  Block lists are generally not public and access
   to them might need different restrictions (for legal reasons).

 - IP-level blocking leads to more overblocking (anything sharing the
   same IP); this causes legal problems.

So Marco's arguments seem reasonable.

>> > * Cloudflare can falsify DNS¹
>> You can use DNSSEC over DoH.
>
> If implemented.

It's probably easier to use DNSSEC with DoH as you avoid broken
resolvers at ISP or customer routers that don't speak DNSSEC or not even
proper DNS.  I've encountered customer routers that knew only about `A`
RRs and lied about `PTR` which breaks stuff in interesting ways...

Ansgar



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Adam Borowski
On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote:
> On Sep 09, Adam Borowski  wrote:
> 
> > With DoH:
> > * the target server knows about you (duh!)
> > * the ISP can read the destination of every connection
> >   [reading the IP header, reading SNI header]
> > * the ISP can block such connections
> >   [blocking actual connection]
> Well, no. They cannot without significantly more expensive hardware to 
> do DPI and a *totally different* legislative framework.
> (Source: I have been dealing with government-mandated censorship in 
> Italy for ~15 years, both at technical and policy levels.)

I don't understand how blocking by IP would be any more expensive than
blocking by DNS.  It's _cheaper_: you read a field in the IP header instead
of doing it in a higher level DNS server.

> > * Cloudflare can falsify DNS¹
> You can use DNSSEC over DoH.

If implemented.

> You obviously consider Mozilla's choices of trusted resolvers (currently 
> Cloudflare, hopefully others too in the future) a bigger privacy risk 
> for generic users (the one who use the browser defaults) than their ISP, 
> I disagree.

Currently you need to trust the ISP; with DoH you need to trust both the ISP
and Cloudflare.  Unless you tunnel all the data over DNS (iodine), you need
to contact your actual destination over open network.

> I still believe that generic users are better served by deploying more 
> censorship-resistant protocols than by worrying that Cloudflare (or 
> whoever else) would violate the privacy requirements mandated by 
> Mozilla.

Sure, but DoH is less censorship-resistant not more.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-12 Thread Marc Haber
On Mon, 9 Sep 2019 00:38:03 +0200, Adam Borowski 
wrote:
>With local DNS:
>* the target server knows about you (duh!)
>* the ISP can read the destination of every connection
>  [reading the DNS packets, reading the IP header, reading SNI header]
>* the ISP can block such connections
>  [blocking DNS packets, blocking actual connection]
>* DNSSEC forbids falsifying DNS
>
>With DoH:
>* the target server knows about you (duh!)
>* the ISP can read the destination of every connection
>  [reading the IP header, reading SNI header]
>* the ISP can block such connections
>  [blocking actual connection]
>* Cloudflare can read the destination of every connection
>  [they serve the DNS...]
>* Cloudflare can falsify DNS¹
>* Cloudflare can block connections
>  [blocking or falsifying DNS response]
>
>So currently DoH is strictly worse.

Will DOH break corporate web apps that are accessed over a VPN (and
thus only resolvable via the local resolver)? Or has Mozilla catered
for that?

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



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-11 Thread Ulrike Uhlig
Hi!

Thank you for raising this topic!

On 09.09.19 07:56, Ondřej Surý wrote:

> We can discuss (and it has been discussed) ad nauseam, but the point is that 
> nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
> believe it’s in the line with other Debian work that we should not send data 
> to 3rd party DNS service without explicit user consent.

I have a question besides the DOH discussion: How is this technically
done to target "only" US users?

Note: I have not looked up any documentation provided by Mozilla, I was
just wondering.

Cheers!
Ulrike



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-11 Thread Andy Simpkins




On 11/09/2019 06:16, Ingo Jürgensmann wrote:

Am 10.09.2019 um 07:50 schrieb Florian Lohoff :


On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.


I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not.




I appreciate that Mozilla are trying to enhance privacy by introducing 
DoH as an option (but clearly not for children! [0][1]), but are we not 
missing the major point here?  DNS does not belong in the browser


If we wish to deploy DoH (I think it would get my vote) then it should 
be system wide and transparent to applications, using the same methods 
already available.  If every application were to deploy its own resolver 
service then total chaos will ensue.


Yes I know browsers offer alternative resolve / and proxy methods 
already, unfortunately that ship has already sailed. Providing that they 
are turned OFF by default then that is acceptable.  With in-browser DoH 
again, as long as it is OFF by default I don't see an issue.


/Andy

[0] "Respect user choice for opt-in parental controls and disable DoH if 
we detect them" 
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/


[1] In browser DoH will break a lot of 'parental control / supervisor' 
applications that block traffic based on black & white lists.  IMO this 
is another reason why DoH shouldn't be inside the browser - already 
Mozilla are deploying work arounds for certain use cases...




Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-11 Thread Ingo Jürgensmann
Am 10.09.2019 um 07:50 schrieb Florian Lohoff :

> On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
>> I for one, do trust my ISPs a lot more than I trust Cloudflare or
>> Google, simply based on the jurisdiction.
> There are tons of setups which are fine tuned for latency because they
> are behind sat links etc or low bandwidth landlines. They have dns
> caches with prefetching to reduce typical resolve latency down to sub
> milliseconds although your RTT to google/cloudflare is >1000ms.
> 
> Switching from your systems resolver fed by DHCP to DoH in Firefox will
> make the resolve latency go from sub ms to multiple seconds as the
> HTTP/TLS handshake will take multiple RTT. This will effectively break
> ANY setup behind Sat links e.g. for example all cruise ships at
> sea.

I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc





Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Anthony DeRobertis



On September 8, 2019 10:38:03 PM UTC, Adam Borowski  wrote:

>DoH doesn't stop ISP-based spying nor censorship. 

Firefox, I believe, already supports encrypted SNI (in nightly at least). 
Cloudflare does too. 

So fully deployed, your ISP can only tell that you're connecting to Cloudflare, 
Cloudfront, Akamai, Fastly, etc. At least when you're browsing sites using 
those CDNs. 

Trusting those parties is a huge can of worms, of course, but Mozilla has at 
least contractually limited what Cloudflare can collect and keep[1]. And the 
alternative for a lot of us is Verizon or Comcast. 

That said, ideally it'd be something that each user would be prompted about on 
first run, being given a clear description and asked if he/she wants it or not. 
But since upstream hasn't AFAIK coded that, it's not going to happen. 


[1] 
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Jeremy Stanley
On 2019-09-10 19:56:48 +0200 (+0200), Julien Cristau wrote:
[...]
> How is this worse than what we're already doing by default, namely
> sending the same data to whoever happens to be on the network, in
> addition to whoever happened to be listed in an unauthenticated
> dhcp response? (Which, if you're lucky, is your ISP, aka a 3rd
> party.)

It still significantly distributes the work of recording your DNS
queries/Web browsing activity. Cloudflare and their competitors are
already well-placed to see a significant proportion of general Web
traffic due to their CDN businesses, which makes them a much more
attractive target for mass surveillance (either mandated by some
governments, for sale to the highest bidders, or simply as the
victims of a stealthy criminal incursion). That status increases if
they're also the de facto DNS resolver for a majority of Firefox
users. I think it comes down to whether you consider the biggest
privacy risk to come from focused/local attacks (in which case the
new default is a benefit) or from global dragnet trawling by "big
brother" (in which case nearly everyone in the World trusting the
same small number of companies is a problem).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Julien Cristau
On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote:

> > On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> > 
> > I for one, do trust my ISPs a lot more than I trust Cloudflare or
> > Google, simply based on the jurisdiction.
> 
> While I still strongly agree with you on this one (even though I think all
> major ISPs here are scumbags, especially the incumbent), I still strongly
> think we should not have this debate here, and we should turn this around
> the usual Debian policy - to not send data to 3rd party without explicit user
> content and defaulting to not doing so.
> 
How is this worse than what we're already doing by default, namely
sending the same data to whoever happens to be on the network, in
addition to whoever happened to be listed in an unauthenticated dhcp
response?  (Which, if you're lucky, is your ISP, aka a 3rd party.)

Cheers,
Julien



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Marco d'Itri
On Sep 09, Adam Borowski  wrote:

> With DoH:
> * the target server knows about you (duh!)
> * the ISP can read the destination of every connection
>   [reading the IP header, reading SNI header]
> * the ISP can block such connections
>   [blocking actual connection]
Well, no. They cannot without significantly more expensive hardware to 
do DPI and a *totally different* legislative framework.
(Source: I have been dealing with government-mandated censorship in 
Italy for ~15 years, both at technical and policy levels.)

> * Cloudflare can falsify DNS¹
You can use DNSSEC over DoH.

You obviously consider Mozilla's choices of trusted resolvers (currently 
Cloudflare, hopefully others too in the future) a bigger privacy risk 
for generic users (the one who use the browser defaults) than their ISP, 
I disagree.

I still believe that generic users are better served by deploying more 
censorship-resistant protocols than by worrying that Cloudflare (or 
whoever else) would violate the privacy requirements mandated by 
Mozilla.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Ondřej Surý
> On 10 Sep 2019, at 09:38, Yao Wei  wrote:
> 
> On Tue, Sep 10, 2019 at 08:24:03AM +0200, Ondřej Surý wrote:
>> While I still strongly agree with you on this one (even though I think all
>> major ISPs here are scumbags, especially the incumbent), I still strongly
>> think we should not have this debate here, and we should turn this around
>> the usual Debian policy - to not send data to 3rd party without explicit user
>> content and defaulting to not doing so.
> 
> Should we propagate our concerns to Mozilla?

These concerns has been voiced to them multiple times by multiple people
and they won’t budge as they already made their minds.

Ondrej
--
Ondřej Surý
ond...@sury.org



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Yao Wei
On Tue, Sep 10, 2019 at 08:24:03AM +0200, Ondřej Surý wrote:
> While I still strongly agree with you on this one (even though I think all
> major ISPs here are scumbags, especially the incumbent), I still strongly
> think we should not have this debate here, and we should turn this around
> the usual Debian policy - to not send data to 3rd party without explicit user
> content and defaulting to not doing so.

Should we propagate our concerns to Mozilla?

Yao Wei


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-10 Thread Ondřej Surý
> On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> 
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

While I still strongly agree with you on this one (even though I think all
major ISPs here are scumbags, especially the incumbent), I still strongly
think we should not have this debate here, and we should turn this around
the usual Debian policy - to not send data to 3rd party without explicit user
content and defaulting to not doing so.

Ondrej
--
Ondřej Surý
ond...@sury.org



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-09 Thread Florian Lohoff
On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-09 Thread Bjørn Mork
Ondřej Surý  writes:

> On the privacy topic...
>
> Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
> Paper: https://dl.acm.org/authorize.cfm?key=N687437

And also section 8 of
https://tools.ietf.org/html/draft-reid-doh-operator-00


> And you can get to the video recording from the ANRW 2019 pages: 
> https://irtf.org/anrw/2019/program.html
>
> We can discuss (and it has been discussed) ad nauseam, but the point
> is that nobody (certainly I am not) is asking for crippling DoH, but I
> just strongly believe it’s in the line with other Debian work that we
> should not send data to 3rd party DNS service without explicit user
> consent.

I agree, FWIW. User consent is required.

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

> Otherwise it doesn’t make any sense to remove external links to logos
>and JavaScript from the documentation and then send everything to one
>single US-based provider.

Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


Bjørn



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-09 Thread Robert Edmonds
The entire DNS root zone is only 1 MB compressed and is updated about
once a day. It would be even better for privacy if the whole root zone
were distributed via HTTPS, as the initiator would not reveal to the
server any information about what TLD is being looked up.

There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
of bandwidth required by a query/response pair of UDP DNS packets to
obtain the delegation for a TLD.

The size of the DNS root zone could also be reduced if it were signed by
an ECC algorithm rather than RSA.

If the ZONEMD resource record (draft-ietf-dnsop-dns-zone-digest) were
standardized and deployed in the root zone, it would allow for
cryptographic verification of the entire contents of the root zone
regardless of the source. So it would not even be necessary to obtain
the root zone from the "official" root name server infrastructure.

That moves the problem down a level to the TLDs, where it is
impracticable to distribute copies of all TLD zone files. So a better
question to ask would be whether any of the DNS TLD servers plan to
implement any of the DNS transport privacy options. That moves the
problem down another level, etc.

The benefit of encrypting the resolver to authoritative side of the DNS
protocol is that it makes it possible to deploy "non stub" caching DNS
resolvers to individual hosts without exposing the plaintext lookup
traffic to either network observers or a centralized resolver operator
such as an ISP or cloud provider.

Ondřej Surý wrote:
> DNSCurve - probably never
> 
> DoT - the current profiles are stub to resolver, when they are profiles for 
> resolver to authoritative and a solid support in the software, the RSSAC will 
> surely talk about this. The deployment will have impact (switching all 
> traffics to TCP? Yay?)
> 
> DoH - I am not sure what would be the benefit for resolver to authoritative, 
> but same as with DoT.
> 
> DNSoQUIC - not yet there, but it might be better option for resolver to 
> authoritative...
> 
> Ondřej
> --
> Ondřej Surý 
> 
> > On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> > 
> > On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> > 
> >> Mozilla plans to enable DoH to CloudFlare by default to US based users
> > 
> > Does anyone know if there is any plan for the DNS root servers to
> > enable any of the DNS privacy options? AFAIK the available options are
> > DNSCurve, DoT or DoH.
> > 
> > -- 
> > bye,
> > pabs
> > 
> > https://wiki.debian.org/PaulWise
> > 
> 

-- 
Robert Edmonds
edmo...@debian.org



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Ondřej Surý
On the privacy topic...

Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
Paper: https://dl.acm.org/authorize.cfm?key=N687437

And you can get to the video recording from the ANRW 2019 pages: 
https://irtf.org/anrw/2019/program.html

We can discuss (and it has been discussed) ad nauseam, but the point is that 
nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
believe it’s in the line with other Debian work that we should not send data to 
3rd party DNS service without explicit user consent.

Otherwise it doesn’t make any sense to remove external links to logos and 
JavaScript from the documentation and then send everything to one single 
US-based provider.

Ondrej
--
Ondřej Surý 

> On 8 Sep 2019, at 23:29, Marco d'Itri  wrote:
> 
> On Sep 08, Ondřej Surý  wrote:
> 
>> I would rather see an explicit statement. I would be very surprised 
>> with Debian’s usual stance regarding the users’ privacy that we would 
>> not consider this as a privacy violation, but again I am not Firefox 
>> maintainer in Debian and I would rather hear from them than speculate 
>> on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.
> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.
> 
> -- 
> ciao,
> Marco


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Ondřej Surý
DNSCurve - probably never

DoT - the current profiles are stub to resolver, when they are profiles for 
resolver to authoritative and a solid support in the software, the RSSAC will 
surely talk about this. The deployment will have impact (switching all traffics 
to TCP? Yay?)

DoH - I am not sure what would be the benefit for resolver to authoritative, 
but same as with DoT.

DNSoQUIC - not yet there, but it might be better option for resolver to 
authoritative...

Ondřej
--
Ondřej Surý 

> On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> 
> On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> 
>> Mozilla plans to enable DoH to CloudFlare by default to US based users
> 
> Does anyone know if there is any plan for the DNS root servers to
> enable any of the DNS privacy options? AFAIK the available options are
> DNSCurve, DoT or DoH.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise
> 



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Paul Wise
On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:

> Mozilla plans to enable DoH to CloudFlare by default to US based users

Does anyone know if there is any plan for the DNS root servers to
enable any of the DNS privacy options? AFAIK the available options are
DNSCurve, DoT or DoH.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Adam Borowski
On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
> On Sep 08, Ondřej Surý  wrote:
> 
> > I would rather see an explicit statement. I would be very surprised 
> > with Debian’s usual stance regarding the users’ privacy that we would 
> > not consider this as a privacy violation, but again I am not Firefox 
> > maintainer in Debian and I would rather hear from them than speculate 
> > on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.

DoH doesn't stop ISP-based spying nor censorship.  On the other hand, it
allows a new third party (Cloudflare in Mozilla's default) to do both such
spying and censorship -- something it couldn't do before.

Let's compare; by "ISP" I mean every hop on the network path.

With local DNS:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the DNS packets, reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking DNS packets, blocking actual connection]
* DNSSEC forbids falsifying DNS

With DoH:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking actual connection]
* Cloudflare can read the destination of every connection
  [they serve the DNS...]
* Cloudflare can falsify DNS¹
* Cloudflare can block connections
  [blocking or falsifying DNS response]

So currently DoH is strictly worse.

In the future, once ESNI is implemented and deployed, the ISP will lose the
possibility of distinguishing sites served from the same IP, but that helps
with some random blogs while most sensitive sites can't trust a shared
hoster.  Thus, ESNI hardly helps.

> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.

If that feature worked, that'd would indeed be terrible.  But in the current
proposal, it's a privacy violation with no clear upside.  I'd thus recommend
to _not_ enable DoH in our packages.


Meow!

[1]. It would be possible to, instead of sending just the answer, to pass
the entire chain of DNSSEC signatures over the DoH link.  This has been
suggested in RFC8484, but doesn't seem to be implemented by Firefox.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Snowflakes?  Socks drawer!
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄



Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Jeremy Stanley
On 2019-09-08 23:17:13 +0200 (+0200), Marco d'Itri wrote:
[...]
> I think that this is a privacy enhancement, since it prevents some
> major ISPs from spying on users DNS queries.
[...]

While at the same time legitimizing Cloudflare spying on users' DNS
queries, right? How is one necessarily better than the other? My ISP
can spy on far fewer users than Cloudflare can, so on balance this
seems like a net loss for privacy.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Marco d'Itri
On Sep 08, Ondřej Surý  wrote:

> I would rather see an explicit statement. I would be very surprised 
> with Debian’s usual stance regarding the users’ privacy that we would 
> not consider this as a privacy violation, but again I am not Firefox 
> maintainer in Debian and I would rather hear from them than speculate 
> on my own.
I think that this is a privacy enhancement, since it prevents some major 
ISPs from spying on users DNS queries. When it will be enabled in other 
countries it will prevent government-mandated (or "encouraged")
censorship.
It would be a terrible signal if Debian decided to disable an 
anti-censoship feature provided by an upstream vendor.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Mozilla Firefox DoH to CloudFlare by default (for US users)?

2019-09-08 Thread Ondřej Surý
Hi,

I haven’t found any discussion on the topic (although I haven’t searched very 
hard and only looked for DoH and DNS keywords in the BTS), but since Mozilla 
plans to enable DoH to CloudFlare by default to US based users: 
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
 I would rather see an explicit statement. I would be very surprised with 
Debian’s usual stance regarding the users’ privacy that we would not consider 
this as a privacy violation, but again I am not Firefox maintainer in Debian 
and I would rather hear from them than speculate on my own.

Thanks,
Ondřej
--
Ondřej Surý 

Mozilla Firefox

2019-08-17 Thread patrick . dreier

Sehr geehrte Damen und Herren!

Mozilla Firefox:
http://ftp.mozilla.org/pub/firefox/releases/68.0.2/linux-x86_64/en-US/

Mit freundlichen Grüssen!



Mozilla Firefox

2019-08-17 Thread patrick . dreier

Sehr geehrte Damen und Herren!

Mozilla Firefox:
http://ftp.mozilla.org/pub/firefox/releases/68.0.2/linux-x86_64/en-US/

Mes meilleurs Salution!



Re: Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

2019-07-15 Thread Marvin Renich
* patrick.dre...@gmx.net  [190714 14:24]:
> Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and
> 32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field
> 32-bit i386 for Adobe Reader ftp.adobe.com

All of your recent posts to this list (debian-devel@lists.debian.org)
are more appropriate for the debian-user mailing list
(debian-u...@lists.debian.org).  In the future, please ask for help
there first.

Debian already has multi-architecture support, and running 64-bit
(amd64) and 32-bit (i386) programs simultaneously on a system whose
hardware supports amd64 instructions has been possible for a number of
years now.  A Google search for debian multiarch or debian
multiarchitecture will both give you the Debian Multiarch HOWTO wiki
page as the first result.

Please try to help yourself before asking others to spoon feed you
answers.

When you have suggestions, please try to determine the current status of
those features in Debian (e.g. Multiarch or Firefox vs Firefox ESR).
Asking on debian-user is a good resource for this; debian-devel is not
the right place to ask these questions.  If you determine that the
feature does not exist, familiarize yourself with the Debian Bug
Tracking System <https://www.debian.org/Bugs/> and determine the
appropriate package (e.g. lxde or debian-installer) and file a bug on
that package with severity wishlist.  If you are having trouble
determining which package is appropriate, ask on the debian-user mailing
list.  The command reportbug, which is installed on a default Debian
installation, can help you through the process of filing a bug and
setting the appropriate severity.  All feature requests should have
severity wishlist.

Debian already has a number of PDF readers; ask on debian-user if you
cannot find one you like by searching with Google (or using synaptic or
one of the other package managers on your Debian system).

To reiterate, try to use search engines like Google or DuckDuckGo first.
If that doesn't work, ask on debian-user or some other user support
channel.  There is also a debian-user-french mailing list if that would
be easier for you.

...Marvin



Re: Proposition: Insert Mozilla Firefox Release in Debian

2019-07-14 Thread Russ Allbery
The Wanderer  writes:
> On 2019-07-14 at 22:03, Paul Wise wrote:
>> On Sun, Jul 14, 2019 at 9:57 PM  wrote:

>>> Please Insert Mozilla Firefox Release in Debian.

>> Mozilla Firefox is available in Debian, the package name is
>> firefox-esr.

> That's the ESR version. I read this as being a request to include the
> "release" version, i.e., mainline non-ESR.

> My understanding is that that's a nonstarter for one reason and another,
> but I don't recall all the specifics involved.

It's there, it's the firefox package.  It's just not included in stable
releases because it doesn't get security support for the lifetime of
stable, so doesn't meet our stable guarantees.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>



Re: Proposition: Insert Mozilla Firefox Release in Debian

2019-07-14 Thread The Wanderer
On 2019-07-14 at 22:03, Paul Wise wrote:

> On Sun, Jul 14, 2019 at 9:57 PM  wrote:
> 
>> Please Insert Mozilla Firefox Release in Debian.
> 
> Mozilla Firefox is available in Debian, the package name is
> firefox-esr.

That's the ESR version. I read this as being a request to include the
"release" version, i.e., mainline non-ESR.

My understanding is that that's a nonstarter for one reason and another,
but I don't recall all the specifics involved.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Proposition: Insert Mozilla Firefox Release in Debian

2019-07-14 Thread Paul Wise
On Sun, Jul 14, 2019 at 9:57 PM  wrote:

> Please Insert Mozilla Firefox Release in Debian.

Mozilla Firefox is available in Debian, the package name is firefox-esr.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

2019-07-14 Thread patrick . dreier

Dear Woman and Man!

Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and
32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field
32-bit i386 for Adobe Reader ftp.adobe.com

With kind Greetings!



Proposition: Insert Mozilla Firefox Release in Debian

2019-07-14 Thread patrick . dreier

Dear Woman and Man!

Please Insert Mozilla Firefox Release in Debian.

With kind Greetings!



Re: Bug: can't install Mozilla Firefox

2019-06-23 Thread Marvin Renich
* patrick.dre...@gmx.net  [190623 17:24]:
> Fear Woman and Man!
> 
> In the system is the ESR version. I will have the Release version.
> Bug: can't install Mozilla Firefox.
> apt remove firefox*
> apt purge firefox*
> apt install firefox
> How can resolve this?
> 
> With kind Greetings!
> 

I think the package you want is firefox-esr, although firefox is in
unstable but not stable or testing.  This is a user question; please ask
for help on .

...Marvin



Bug: can't install Mozilla Firefox

2019-06-23 Thread patrick . dreier

Fear Woman and Man!

In the system is the ESR version. I will have the Release version.
Bug: can't install Mozilla Firefox.
apt remove firefox*
apt purge firefox*
apt install firefox
How can resolve this?

With kind Greetings!



Bug#921519: ITP: mozilla-deepspeech -- TensorFlow implementation of Baidu's DeepSpeech architecture

2019-02-06 Thread Jonathan Carter
Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: mozilla-deepspeech
  Version : 0.5.0-alpha.1
  Upstream Author : Mozilla
* URL : https://github.com/mozilla/DeepSpeech
* License : MPL-2.0
  Programming Lang: Python
  Description : TensorFlow implementation of Baidu's DeepSpeech architecture

Project DeepSpeech is an open source Speech-To-Text engine, using a model
trained by machine learning techniques, based on Baidu's Deep Speech research
paper. Project DeepSpeech uses Google's TensorFlow project to make the
implementation easier.

I plan to main this package on the Debian team on salsa.debian.org, and
intend on using this in future projects that will be packaged in Debian.



Bug#917282: ITP: lz4json -- unpack lz4json files, usually generated by Mozilla programs

2018-12-25 Thread Adam Borowski
Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: lz4json
  Version : ?
  Upstream Author : Andi Kleen
* URL : https://github.com/andikleen/lz4json
* License : BSD-2 ish
  Programming Lang: C
  Description : unpack lz4json files, usually generated by Mozilla programs
 Instead of a standard .json.lz4, Firefox uses its own format to compress
 its bookmarks and session restore files.  This tool lets you read them,
 converting to json.  Going from json to a human-readable format is then
 up to you.



Accepted mozilla-devscripts 0.53 (source) into unstable

2018-10-04 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 04 Oct 2018 20:58:54 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.53
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Closes: 909527
Changes:
 mozilla-devscripts (0.53) unstable; urgency=medium
 .
   * Team upload.
   * Open files with utf-8 encoding by default. (Closes: #909527)
Checksums-Sha1:
 394e8806997c27789912a66bee5d82a706612011 1169 mozilla-devscripts_0.53.dsc
 9b037d9099807262a98d9ade8c465e5064bafb7d 42252 mozilla-devscripts_0.53.tar.xz
 7942415764e35a752f1a79b10cbe9921fff76371 6427 
mozilla-devscripts_0.53_source.buildinfo
Checksums-Sha256:
 133ac79a79fd7a6271148383c3d19b934c1b51d25ec02c4441ae9eb95a059b1a 1169 
mozilla-devscripts_0.53.dsc
 7c960b7904850e62542822138fa0e8636c418a9fa40e4d64c38f8200d3b821a3 42252 
mozilla-devscripts_0.53.tar.xz
 e345f84194c67f7fe48a46f419e2aa953007e8184c1c4a4f176dc2d51fc500d8 6427 
mozilla-devscripts_0.53_source.buildinfo
Files:
 82610d554ffedd3b4f38a332a9cddea7 1169 devel optional 
mozilla-devscripts_0.53.dsc
 0326000d542d02e8089c4379a5cefb22 42252 devel optional 
mozilla-devscripts_0.53.tar.xz
 5a9be3c7624760a9526104473d887795 6427 devel optional 
mozilla-devscripts_0.53_source.buildinfo

-BEGIN PGP SIGNATURE-

iHQEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW7bhmAAKCRDrH8jaRfsp
MKWDAPdGJnKKZ9/Hozvd79gZhO0N7xi9hmz0nlD8pv4HbFbEAPoC3YHLAjGTFiHU
m95bViMC3pEIeCzWCRAKiKDhbtkMAw==
=goNk
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.52 (source) into unstable

2018-09-25 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 25 Sep 2018 00:34:46 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.52
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Changes:
 mozilla-devscripts (0.52) unstable; urgency=medium
 .
   * Team upload.
   * Ignore unknown CLI args so build-indep works properly.
Checksums-Sha1:
 5034bc1a30a489c6d0aba8abe1b0fc1b78566e94 1169 mozilla-devscripts_0.52.dsc
 a197dddab37aea863a38da668b40ae8cadcee6a3 42188 mozilla-devscripts_0.52.tar.xz
 eed20710d27466c176ba634b489cced45b6eeb90 6428 
mozilla-devscripts_0.52_source.buildinfo
Checksums-Sha256:
 f0350fd02f5d91a6e0b888fed98d052f758c43e8d6f4340f0078ea3a7c390678 1169 
mozilla-devscripts_0.52.dsc
 06c146273251141ee8260d3f997e01c537231d5fcc52b987fdff4eb3c0a56274 42188 
mozilla-devscripts_0.52.tar.xz
 f13c492bd8ed76d43a6ddae9e461867d4ca5816cf4c69604e0167a9881859fa2 6428 
mozilla-devscripts_0.52_source.buildinfo
Files:
 377a015a25fe1c48f2a64318a98407f5 1169 devel optional 
mozilla-devscripts_0.52.dsc
 4dd7315428963fc7622e658c52cea446 42188 devel optional 
mozilla-devscripts_0.52.tar.xz
 a48e9553b93d7ced5d3f5a5d038719f2 6428 devel optional 
mozilla-devscripts_0.52_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW6nlLwAKCRDrH8jaRfsp
MJGTAP9HyNSHGHhgqBS3kcW16qs8E9u7dy/olgtTX+n7/rA73AEA+rqoAgJ8puCb
hLa3kHAulcU+pQforrbpcFOCCgvyYAA=
=bzBQ
-END PGP SIGNATURE-



Accepted mozilla-noscript 10.1.9.6-2 (source) into unstable

2018-09-25 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 24 Sep 2018 23:15:50 -0700
Source: mozilla-noscript
Binary: webext-noscript xul-ext-noscript
Architecture: source
Version: 10.1.9.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 webext-noscript - permissions manager for Firefox
 xul-ext-noscript - Show browser tabs like a tree - transitional package
Changes:
 mozilla-noscript (10.1.9.6-2) unstable; urgency=medium
 .
   * Team upload.
   * Remove obsolete file in source packaging.
   * Force rebuild against mozilla-devscripts 51 for less strict dependencies.
Checksums-Sha1:
 382c2738494ecc5b2daff69a352735181139c2ba 1550 mozilla-noscript_10.1.9.6-2.dsc
 b669c32c535d6d634eeab9eb49ed3328df59e75a 92048 
mozilla-noscript_10.1.9.6-2.debian.tar.xz
 e5e2f620ba719889e4a82db60d275f4207df3dd6 6412 
mozilla-noscript_10.1.9.6-2_source.buildinfo
Checksums-Sha256:
 d801a8961f881e349f9d7f3feaf35da3de0b250b4b810377fbe605eb904b5e56 1550 
mozilla-noscript_10.1.9.6-2.dsc
 5cf118f8280192c74941b9c2f70f6ecc0b8fa00452ea66bd8a6c9fb6ed357855 92048 
mozilla-noscript_10.1.9.6-2.debian.tar.xz
 2c666ecfba1a02a5f5570ff21f4d5febaac2bd9d6d03932eea3bf9843af96a18 6412 
mozilla-noscript_10.1.9.6-2_source.buildinfo
Files:
 351565462e08378cdbb08a0c917bbf9c 1550 web optional 
mozilla-noscript_10.1.9.6-2.dsc
 fd26679849a7da50e27592cdf61be6a2 92048 web optional 
mozilla-noscript_10.1.9.6-2.debian.tar.xz
 38ee3083f623e85e8a5bb208923c6dd5 6412 web optional 
mozilla-noscript_10.1.9.6-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW6nSuQAKCRDrH8jaRfsp
MPJmAQC/cd+xGXZs3Cbb2u1+8/ZKqcUsYLgwa9Od4J91z6mkzwEAzMkA7AMKLf4v
SackdeIbM7zaCUECkGAzP+tqhyOs+gw=
=u2oN
-END PGP SIGNATURE-



Accepted mozilla-noscript 10.1.9.6-1 (source all) into unstable, unstable

2018-09-24 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 22 Sep 2018 23:25:18 -0700
Source: mozilla-noscript
Binary: webext-noscript xul-ext-noscript
Architecture: source all
Version: 10.1.9.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 webext-noscript - permissions manager for Firefox
 xul-ext-noscript - Show browser tabs like a tree - transitional package
Closes: 882287
Changes:
 mozilla-noscript (10.1.9.6-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release. (Closes: #882287)
   * Use dh_webext instead of dh_xul-ext.
   * Update to latest Standards-Version; no changes required.
Checksums-Sha1:
 fbb729a707e0ab57bc65d0d859e175d921ae3711 1553 mozilla-noscript_10.1.9.6-1.dsc
 fb63b3434c23d6d7efe8b19d6f7c3a7dc674461e 382888 
mozilla-noscript_10.1.9.6.orig.tar.xz
 13b3d0851110cbd4a7b2d6e322548567247834a0 133988 
mozilla-noscript_10.1.9.6-1.debian.tar.xz
 be39640a21384eb221832ec3550e241ce2c0 6955 
mozilla-noscript_10.1.9.6-1_amd64.buildinfo
 b0d1e2dcd5735d1dde3f7bbe4823bd2ff866fc52 535984 
webext-noscript_10.1.9.6-1_all.deb
 b3f875c5a7150c634885a7b207460bec5b70166c 148704 
xul-ext-noscript_10.1.9.6-1_all.deb
Checksums-Sha256:
 71a9ed696f852b3af19ceb4ae2bc4bc5c332911be6a9bc17a87ce966fe5dc6f3 1553 
mozilla-noscript_10.1.9.6-1.dsc
 28c3ad2a50e2c110304057ac96d5c46b3ad212b45f9cd93ac79527853ac87368 382888 
mozilla-noscript_10.1.9.6.orig.tar.xz
 c72c16e3dcb85cbfab70c5b78f0c1914df228e7f01c430d54b88208dd89a20c9 133988 
mozilla-noscript_10.1.9.6-1.debian.tar.xz
 3b672f0391b806131aa8dfad95f969f58ed5068ac85faa1a70b63a678b4fb004 6955 
mozilla-noscript_10.1.9.6-1_amd64.buildinfo
 d487543125e66ca142a5f58cbe80e7d8087cd823f46779640c1fa28931220694 535984 
webext-noscript_10.1.9.6-1_all.deb
 4cab4cb7f8489bcee4106f8733f25893a8b64a247da7edaea4095eab4a7db7a8 148704 
xul-ext-noscript_10.1.9.6-1_all.deb
Files:
 064681ab7bbfafbb462eb9ccf4dc2859 1553 web optional 
mozilla-noscript_10.1.9.6-1.dsc
 26e94555f140128457fcb2000174672c 382888 web optional 
mozilla-noscript_10.1.9.6.orig.tar.xz
 85c0afd382c0890470f3ed4fea99076c 133988 web optional 
mozilla-noscript_10.1.9.6-1.debian.tar.xz
 62dba7ea826d96b5f0960b3b889da204 6955 web optional 
mozilla-noscript_10.1.9.6-1_amd64.buildinfo
 9a3ed2100cdda05d077f2d7618dad65b 535984 web optional 
webext-noscript_10.1.9.6-1_all.deb
 3b8bdd6a9b6d5834d23ea54062b1a50b 148704 oldlibs optional 
xul-ext-noscript_10.1.9.6-1_all.deb

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW6cx9AAKCRDrH8jaRfsp
MA8YAP0ZAmQGIP1b1ynMVp1R5Fj85wD6J54Ry8mOKiMdhF55ewD/curEM1QRlSkz
mgQDUZT5IbSwW/4uv9FrOxpK2z1jMgk=
=X0hr
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.51 (source) into unstable

2018-09-23 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 23 Sep 2018 14:31:35 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.51
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Changes:
 mozilla-devscripts (0.51) unstable; urgency=medium
 .
   * Relax generated Depends to Recommends to avoid forcing upgrades of
 old browsers just because new extensions don't work on them.
   * Generate versioned Provides.
Checksums-Sha1:
 40a6ea86da94ddf4ee8572ee3d05639129a0891c 1169 mozilla-devscripts_0.51.dsc
 2c0c274e7fda329558cc36928f6c6780218d0076 42100 mozilla-devscripts_0.51.tar.xz
 aa0d4afc0b914cb1f487306c884b4644a256f142 6428 
mozilla-devscripts_0.51_source.buildinfo
Checksums-Sha256:
 a53fabe076b15c6a13f692897fc15397d98a78fbea1a351bceec3f1fe8751776 1169 
mozilla-devscripts_0.51.dsc
 fb764f4a9f252246d72d11679ee14afe7775bc7674b046d2d838630f2363432f 42100 
mozilla-devscripts_0.51.tar.xz
 a9fead7e7ab539ad2df2d29e97bf0df12f23250407d1e9a441d3ef0df98406e0 6428 
mozilla-devscripts_0.51_source.buildinfo
Files:
 73f5b1d2ebf7eac9af4703a25b3ad8f9 1169 devel optional 
mozilla-devscripts_0.51.dsc
 67bb6384ba09d9464ac946f19728aa73 42100 devel optional 
mozilla-devscripts_0.51.tar.xz
 a1bcef11716c4c3f470c3580d801d80d 6428 devel optional 
mozilla-devscripts_0.51_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW6gGUAAKCRDrH8jaRfsp
MMv+APwNtULNePPz9+ARU6qfaRCX6d2NuGPCqrL3hHm0FpxJbwEAuwVNmoslyNVO
Gq4ql6Cn2C4xMaOO6DzmkAHgnxKDtgA=
=KDVH
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.50 (source) into unstable

2018-09-23 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 22 Sep 2018 22:39:25 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.50
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Changes:
 mozilla-devscripts (0.50) unstable; urgency=medium
 .
   * Team upload.
   * dh_webext: Try to autodetect more things to avoid users having to define
 override_dh_webext themselves.
   * Prevent setuptools fucking up the shebang line of dh_webext which meant
 that the previous release was actually broken.
   * Use similar logic as dh_xul-ext to generate Depends, Enhances, and Breaks.
Checksums-Sha1:
 4d812403ede67bbe09d0aefbe62c6b4b986c5881 1169 mozilla-devscripts_0.50.dsc
 138190a9ee24716493d72f2efe5415395f87b289 41968 mozilla-devscripts_0.50.tar.xz
 60bedf55b05d120b2d7f06d865028ef46c55ec1d 6428 
mozilla-devscripts_0.50_source.buildinfo
Checksums-Sha256:
 72754b5463fa377f21c31445e6250f7824b2905a3038c1f01c2e519544ba1c9d 1169 
mozilla-devscripts_0.50.dsc
 ffd15c7a0e7e1d2812b7cc1e149bc21c69951c246218806e3961faffe0397ddd 41968 
mozilla-devscripts_0.50.tar.xz
 864bbb28cf186178327dad04e31a91836fb60b3eb8951f8f29dcb04911c5c377 6428 
mozilla-devscripts_0.50_source.buildinfo
Files:
 ce460acba49abe5ffc1bdc09be58cf29 1169 devel optional 
mozilla-devscripts_0.50.dsc
 b86ae4a6f40584d043440f9822431d48 41968 devel optional 
mozilla-devscripts_0.50.tar.xz
 d6ebb0577829300879f75aa982f77ff9 6428 devel optional 
mozilla-devscripts_0.50_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW6cnJwAKCRDrH8jaRfsp
MIR4AP9zk36iu7Pctgm1DTeqgTsFN3jnk4uKiGhnIoYko/qs4AD9Gr/WvLvJsQyS
Y6tiVS01OgWvnDdhDK5WPPa+mGHZLgc=
=dJye
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.49 (source) into unstable

2018-07-31 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 31 Jul 2018 03:34:57 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.49
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 

Changed-By: Ximin Luo 
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Changes:
 mozilla-devscripts (0.49) unstable; urgency=medium
 .
   * Team upload.
   * More improvements to dh_webext, includes a fix for current Firefox.
 .
   [ Sean Whitton ]
   * Remove myself from the Uploaders field.
Checksums-Sha1:
 1ca2680a5ba53a74c04dc71e03fa2b4438c92e4e 1169 mozilla-devscripts_0.49.dsc
 106e48c23fa7d3b702dbde345916295d22cb1f48 41244 mozilla-devscripts_0.49.tar.xz
 9e2974e505c5de6b7f30460317d9cc6deb21cf15 6422 
mozilla-devscripts_0.49_source.buildinfo
Checksums-Sha256:
 fb348f93ce282dd4af9bdf946396097738bb56a4a21c8bd77d256f25defc3154 1169 
mozilla-devscripts_0.49.dsc
 31a458154702b120c718ae2b9636773fd69702607ea5a900f8c4d76282ae582c 41244 
mozilla-devscripts_0.49.tar.xz
 fe182faa7f415924eaeb0971e42cbd70515b073095922bf43f5bcdad5b5fa74a 6422 
mozilla-devscripts_0.49_source.buildinfo
Files:
 27b086fa3ee51944ca1027bfcfedb43d 1169 devel optional 
mozilla-devscripts_0.49.dsc
 0bb98867f3c6c6142d3688d4fe508c9e 41244 devel optional 
mozilla-devscripts_0.49.tar.xz
 c2145b6c87b73026b409f0ccebe66264 6422 devel optional 
mozilla-devscripts_0.49_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQReYinNQ9GpZ9TYcRrrH8jaRfspMAUCW2A7pAAKCRDrH8jaRfsp
MNkZAP4rI6zI9CCjmgB4jH9IYxZGVLgrdZuousGnVnjrDocTxgEA5rOcA/e604oa
pJpHLO29t6nnyGxFY3KRMEJD1sV3Twg=
=QAS/
-END PGP SIGNATURE-



Accepted pkg-mozilla-archive-keyring 1.2 (source all) into unstable

2018-05-27 Thread Mike Hommey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 28 May 2018 09:11:51 +0900
Source: pkg-mozilla-archive-keyring
Binary: pkg-mozilla-archive-keyring
Architecture: source all
Version: 1.2
Distribution: unstable
Urgency: medium
Maintainer: Maintainers of Mozilla-related packages 
<team+pkg-mozi...@tracker.debian.org>
Changed-By: Mike Hommey <gland...@debian.org>
Description:
 pkg-mozilla-archive-keyring - GnuPG archive keys for the Debian Mozilla team 
package repository
Closes: 846892 899787
Changes:
 pkg-mozilla-archive-keyring (1.2) unstable; urgency=medium
 .
   * debian/rules:
 - Touch the keyring before using gpg, so that gpg uses the PGP/GPG
   key public ring (v4) format instead of GPG keybox database version
   1. Closes: #846892.
 - Use a temporary file when creating the keyring.
   * debian/control:
 - Move Maintainer off alioth. Closes: #899787.
 - Bump Standards-Version to 4.1.4.
   * debian/compat, debian/control: Bump to debhelper 10.
   * debian/copyright: Update format URL.
Checksums-Sha1:
 116bdd56b75cceb97be993c875fe1899398c347f 1590 
pkg-mozilla-archive-keyring_1.2.dsc
 1a55061f3154ef695d8ba2628eae18c447771d27 3584 
pkg-mozilla-archive-keyring_1.2.tar.xz
 3cb011a47821f1af3150a4ac7ee5d31f45461e3f 3800 
pkg-mozilla-archive-keyring_1.2_all.deb
 ae67ec1aed632eb04005651cd0da870741a00418 10861 
pkg-mozilla-archive-keyring_1.2_amd64.buildinfo
Checksums-Sha256:
 c969b687aeef20cf44718361d3595491c3a32b8c4386fea205af8650ed906bc7 1590 
pkg-mozilla-archive-keyring_1.2.dsc
 5dd07a4be6a3c0638b4e5511e32031020504c86aea64d9501c8f0fcc82327875 3584 
pkg-mozilla-archive-keyring_1.2.tar.xz
 4f06c563b7162315f5512c02eec04c313544074a020c09da264907e8126b94c5 3800 
pkg-mozilla-archive-keyring_1.2_all.deb
 e3a7ab1805dbeb0d555bbd6e5168a914bd0142fbb8b31079ca1eb53620528f58 10861 
pkg-mozilla-archive-keyring_1.2_amd64.buildinfo
Files:
 244ebceb8eabca40e5bdf1d366f83507 1590 utils extra 
pkg-mozilla-archive-keyring_1.2.dsc
 79294e9870dc8fbd01e7055d69ef506e 3584 utils extra 
pkg-mozilla-archive-keyring_1.2.tar.xz
 55a6302d61b40c5ef77754a24bfac05c 3800 utils extra 
pkg-mozilla-archive-keyring_1.2_all.deb
 3f066c035ee992e39a5de9e073ca0422 10861 utils extra 
pkg-mozilla-archive-keyring_1.2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEGC4WHREwufzNfbFn5CqgT6aqjHIFAlsLSkUACgkQ5CqgT6aq
jHIMUg/+NHiaFhAGKXPsSsc17b3zwSjx5mm4MXtz05XL36BYmVpi+7+QWgBXEEdr
CFwcX2JURYuU3ixu4ysTTcRi9owqUahyZob7fiCpAYTqpZ0sOeNq3JvOolBx8P5F
hRqOVHcSqjvJMFVITFFbpLthPrNIHV4Rvq5UjCbX2g1FX85e6j2E2M6s2XXTo7g9
Jw7OoAKFcTykOCxOnaio+LVXzVxpJoNM52PB4HMgsGiww3DWRnIu/IkaTJFzCP5+
8010sYQJyYBWIpR5t2ueSQ3fTO5OiIgftOOEFd8LvlY9vrrPRRLyRyuTTRCJiTFF
R5IlMl3AHKwT5ShKrI7YNsXVW0t9EtWLemYmmjyri7Ow654j3IavCxBoisg9wBRk
F7NOp4TaANmjcRuASXX8yUb/HxAJR2fdgN3a5245NwOnNTOtX/04EvVFlRK2wXJd
AlCL4YFTcl7uwpGqSRrmv1+svVJrLG8LrEhDRPxA/82ChzrvS4k11So66FqnEHL2
tEpS3Qo9C4PZw/ThqSW3KEynlz/skIQoqrVUyBFSAsHHXBjfP0Q19xNJ7RTM4GjH
TCN7NK/GMy9k/K8cjRwmXNDBEwCjOYNnzpAKFcMOU5McwZqUXo0B1ey1PiPKWhuA
8YkkBy4I4vLk9zHkPsz797IGxUNN4OzC1x5LjOUngSAgaoOSHe0=
=ir5w
-END PGP SIGNATURE-



Accepted mozilla-devscripts 0.48 (source) into unstable

2018-05-18 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 17 May 2018 23:24:28 -0700
Source: mozilla-devscripts
Binary: mozilla-devscripts
Architecture: source
Version: 0.48
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 mozilla-devscripts - Development scripts used by Mozilla's addons packages
Changes:
 mozilla-devscripts (0.48) unstable; urgency=medium
 .
   * Team upload.
   * Add a dh_webext(1) addon to support WebExtensions.
 (Eventually will close #866997, currently WIP.)
Checksums-Sha1:
 3a0e1eef022644b7046dff5be595d7b5c4c5f8b0 1824 mozilla-devscripts_0.48.dsc
 fb7ab01bfe0fb0305f018beb4472a62c0a0c3df5 40652 mozilla-devscripts_0.48.tar.xz
 066e83051c393d5cb5513db09069a5c3fd2b2fb2 6440 
mozilla-devscripts_0.48_source.buildinfo
Checksums-Sha256:
 25669292734ad5c397a08362fa7595aaab70ec3a8e461237f07d68dd55e3d14e 1824 
mozilla-devscripts_0.48.dsc
 023547a6e845018df98a6f648a39a1a4bd6edc80422f05c4714395be677dc402 40652 
mozilla-devscripts_0.48.tar.xz
 0dcebfb0c8587ace386698029280bcd229c722f9bea79b3b41099cc3befb66c7 6440 
mozilla-devscripts_0.48_source.buildinfo
Files:
 624f3f4b974bada606df4a173d554fdc 1824 devel optional 
mozilla-devscripts_0.48.dsc
 beee5780158bfcb10491928425f09e4e 40652 devel optional 
mozilla-devscripts_0.48.tar.xz
 e5f6832abc5c81346d3cc4c9d95490e0 6440 devel optional 
mozilla-devscripts_0.48_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEENmdIajJtsnZtJVVGhg3vO49lC3kFAlr+ca4VHGluZmluaXR5
MEBkZWJpYW4ub3JnAAoJEIYN7zuPZQt5nw0P/3xrxWXdx3W/efeEmh+oe0JGWUum
+HFtxPdL/fBD9uNf17PKpN1Cd1m0e56QzbMcD4qmzxiF1MAQu6r72yZAlxJoZlgY
QOh2yHeh+yaXf8rmGHPPSiWuWbwWIKTgGpDKeh5TiXV/YnKUNybbHsugv/DXAQcB
slRve/CTNLAD+p/ZvCxqJMuyiGchSb8Cwwb8ajmryYO4ju0TxEIVM5m3YgnLorGr
FuwtJbTfnP9H8fdgUSsTtTUctJ6OB1GWTxgttQRDY6LvHOks+bXKE3LTpfDDy0eu
QikQjSTuYa6lGT8i+IxQen10/tflbqc/FTDNcFQLEQNMjMKNLT7euGuvfucwaC58
0HhB4LSMLFoBBHGu++d/aNK05i3+zOyHfSsFWdgoAg8RBCHOBqUbQj7YNF8uQsNb
vqfArLfIwxgMSkLTlubb62f7cNIE78CsO+oRRlVnU4v6xkbRFDbW+8XnrjazU2UB
WgGaIzK90F07FRgeFVXLGOaD+bVpFdIXi1LbhHWI4NMKIjtVajVfE6vaDywRDZjm
7St0rp24RZJKDvnl+w5GkMvNexrTk9VvXxAd/C951HNSwgm4DpSTSpYcF2RVx+f4
1oDQGoSTnyJxElygGn70E356pqhBHhvUPX88N9MoOFiaH3ukqtl4XLYLxivCQtf4
O5p73L6y/nAqo8RB
=+QAr
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.1.7-1 (source) into unstable

2017-11-17 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Nov 2017 16:14:39 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.1.7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.1.7-1) unstable; urgency=medium
 .
   * New upstream version 5.1.7
   * Refresh upstream changelog
Checksums-Sha1:
 71abd070a97b8a5b1ae602fe55b0e1f1847f34b6 1753 mozilla-noscript_5.1.7-1.dsc
 9b40945228f1bb423d96bc758c0cac2d0d64f874 456072 
mozilla-noscript_5.1.7.orig.tar.xz
 1c4a2b4a0fe8dce03644c171327ee12b87534ca6 131236 
mozilla-noscript_5.1.7-1.debian.tar.xz
Checksums-Sha256:
 083c738f425a6452b220a69ec82a869365c9e34122a00bb06bfef07d22985f4a 1753 
mozilla-noscript_5.1.7-1.dsc
 1ac606af9fbf0b72b860c055793960395fc759f18f672009deeb91dc927ccc43 456072 
mozilla-noscript_5.1.7.orig.tar.xz
 ebddd83ec3aa6296edb3704ef8c10e434e56650a0f192862d929082c524397e7 131236 
mozilla-noscript_5.1.7-1.debian.tar.xz
Files:
 1fbc209d9718a1010ffa97bae717c872 1753 web optional mozilla-noscript_5.1.7-1.dsc
 3f2e7e79971ebd17f6a66e9e342ba32d 456072 web optional 
mozilla-noscript_5.1.7.orig.tar.xz
 947e4a36e210d1e22c5a84fa38fae125 131236 web optional 
mozilla-noscript_5.1.7-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAloPnc8ACgkQBYwc+UT2
vTwKkgf/bMXNzEKem2vqT+J5wB0N/iDYBAjkWVB+/zWHKznmKIYceJh7nATj49WA
Y3xxK/JL9ydAcblxdnbp15bon8PcYMvlTMdUts2crhGEwIff9b5/GoOGuRIpvcPr
+tMkQWiLDNrir4Z2lpVeW37weObVJ48n+GhDJP6f5v3E5FwvHivLGxMlQmSRYoaO
A8AQPDoYT19bPcQuMDMKhTzmogVL2Zsfh/rnPVq3jPVJRripTIkx6LeJGm8VWY8z
M2uf/jsqcaFg/ErrnbzoQvZtV0hAhT7xWwu07I3dZkJq4HWOKnygeZ2rzoODhdBR
lWMu/33lhfqrGDa382DHwZRf4sbk5g==
=ojt+
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.1.5-1 (source) into unstable

2017-11-14 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 13 Nov 2017 07:27:58 +1300
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.1.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.1.5-1) unstable; urgency=medium
 .
   * New upstream version 5.1.5, and upload to unstable
   * Refresh upstream changelog
Checksums-Sha1:
 9838befe97470ec420dac9459412c2585bd19690 1753 mozilla-noscript_5.1.5-1.dsc
 71f8fdb3ca848b0493a57f4a0953b7d3ba7ac04b 455952 
mozilla-noscript_5.1.5.orig.tar.xz
 274e30c27aa82b2c9cfb04a0ac5a91c0a31c4179 131108 
mozilla-noscript_5.1.5-1.debian.tar.xz
Checksums-Sha256:
 2e1b6e5955b81a8f63aadb0dbb08bbed55436a6a5f94412859d700f566b1b2f4 1753 
mozilla-noscript_5.1.5-1.dsc
 effa80d77f0aaf0eb376a35a8b10744782b776a80b1662437a5046e6ed1053e3 455952 
mozilla-noscript_5.1.5.orig.tar.xz
 09804ca25c615456f57b19db39ba39a90c36ffc2be5d8e25231698a0b65b944b 131108 
mozilla-noscript_5.1.5-1.debian.tar.xz
Files:
 0350154f52af45e0134a6949025d8288 1753 web optional mozilla-noscript_5.1.5-1.dsc
 bf9d10ff97c54448b6b4cbec5c3e0a90 455952 web optional 
mozilla-noscript_5.1.5.orig.tar.xz
 5888f6f3fcadd3fcaf3f329e4bed4c79 131108 web optional 
mozilla-noscript_5.1.5-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAloItcoACgkQBYwc+UT2
vTy/8gf/TYLUnnbtJVmS/d5uYjJHSk2gKECf3GKx+NP5B9Va95sPOvkzGLpM5Zdm
opgVtHSRJLxjJItoLh3YejHQg7q6lEZAVd/rv2oW+EcemD7rA8vHowmWLiEdCLOs
yrNsqmF/zbN6JavGO4PuVorKEGSKkbCkSXMeWnzFp+D/e6CBvvW0nRFIPYoolK8b
FaWPysv3j4+S3wQV6b5suejz0IgOzN9asjGVLl/2VHmwuSHRviBaBJtYYtspFljP
A5Kuwco13gISsRVX/jeLONCJP0Tit7OwEmnH+vuI8U0xJeJGjNgsmJAWV00PrQiL
n4Vs9ATr+/kxOYcZsmULu3xCsW3Gdg==
=XDvV
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.1.4~rc1-1 (source) into experimental

2017-10-27 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 26 Oct 2017 15:14:29 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.1.4~rc1-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.1.4~rc1-1) experimental; urgency=medium
 .
   * Upload RC to experimental
   * New upstream version 5.1.4~rc1
   * Refresh upstream changelog
Checksums-Sha1:
 063a022949e257098c2d17f67230034bd5b7c404 1781 mozilla-noscript_5.1.4~rc1-1.dsc
 6a55a03fc0e0d7f4b84c1c0b171a3555d0d7ee3d 486124 
mozilla-noscript_5.1.4~rc1.orig.tar.xz
 d3b5db281b5d07e25485b8d967219f3323c491f7 131084 
mozilla-noscript_5.1.4~rc1-1.debian.tar.xz
Checksums-Sha256:
 77a15b2ae36b0fe723db00c97b7c797f7f9086e45ad3b01d01043af2ee81ac75 1781 
mozilla-noscript_5.1.4~rc1-1.dsc
 50953858999d2ec2e4da363267cf8caf1265a8b5483ce0e9ed223e4b9cdc1f28 486124 
mozilla-noscript_5.1.4~rc1.orig.tar.xz
 5e9df78efc4130ad2c5cc858f22272361f713019e4bad0e3d69ae37c246a03f5 131084 
mozilla-noscript_5.1.4~rc1-1.debian.tar.xz
Files:
 1f902c0260ce199594f03fa748761c17 1781 web optional 
mozilla-noscript_5.1.4~rc1-1.dsc
 ec69e2186f509c4cf3a0a9694911967d 486124 web optional 
mozilla-noscript_5.1.4~rc1.orig.tar.xz
 60b56f0c1b951635a54cc32c7d581ce6 131084 web optional 
mozilla-noscript_5.1.4~rc1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlnyibcACgkQBYwc+UT2
vTwODggAlhTn9auYg4sXpB8DRL9FA+4glh+uKdLBYeMNsqCUzl15k1ggs7Cnzkc9
NAynaCaGZzjab9glaDCbl9rNFyaw8TMSh73MnVroz0aP/p+f0FSyt02mM1tKV2zO
Dd3oXyaRCgkEjycHGu0biqTjymC2J3ZZ7/6iRzokirCXxPDDUE4jN6O9K7DMNuaU
XJMHC5y7o7GkDx2QP2NzCQWpmdxvT/icXFabPQrxqf1Kwu8XJtMwUs99V9/kAlvA
msvDLBupwLZGnV8jKrAIN6W7SQNT5mPPDyYHGG96wZFlubKy0SIB0FsxVpKoTHsg
ecn7Da1hCYy6B5xriAsyv5IcIjpF8Q==
=pWPa
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.1.3-1 (source) into unstable

2017-10-27 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 26 Oct 2017 15:09:49 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.1.3-1) unstable; urgency=medium
 .
   * New upstream version 5.1.3
   * Refresh upstream changelog
Checksums-Sha1:
 4909baac99d760065b724e30074f123257f2f50d 1753 mozilla-noscript_5.1.3-1.dsc
 c3f6bd41bf067de3a77c77134594be489a2f9223 486456 
mozilla-noscript_5.1.3.orig.tar.xz
 d27f7c5b6ea6b08360aa0ca8e3a80204687c3a31 130980 
mozilla-noscript_5.1.3-1.debian.tar.xz
Checksums-Sha256:
 0abd4bbee56795a3c3ff9e13807ccd9072e3edc8031534e20d1b7aba1fd29521 1753 
mozilla-noscript_5.1.3-1.dsc
 edaf1027b06fa4f3518e30f90c2d33749b503283899dafda6dca14800475b08d 486456 
mozilla-noscript_5.1.3.orig.tar.xz
 e7f0ed96187a4e899a41deda755dd5956c7abc3b313e76a63ba414e3d8052a69 130980 
mozilla-noscript_5.1.3-1.debian.tar.xz
Files:
 166cc29a31e68f898871bfd139eacf7b 1753 web optional mozilla-noscript_5.1.3-1.dsc
 f64534595d47570244ca899eabfdcc73 486456 web optional 
mozilla-noscript_5.1.3.orig.tar.xz
 1f2096400d95b2604cb0eb009b61 130980 web optional 
mozilla-noscript_5.1.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlnyibYACgkQBYwc+UT2
vTwGvAf/cuIXybVsASOHtFEFQfSOHgm939XX3Y7kNshJhgM1jyN9pRaYtm8QHKQt
2+GMGkbVvus8xif2GX1WxDWzd1y3cupu+806U54qoRBYbzXEZzhROXs5xwpapR3/
eaQ0/dko7RMSQsCifRDK893/KZU2pzpdxtaAWPOHDY/Lry3EynALdsACwsDAMuLR
KgXZu1wukw47Uq2sIAlq61pmm9QDWKg/DfRAePSwlTUcvj38pqCkK0yj9F4YgkIq
A3jYIG0Qdvubh4cFQrz+rddO73Z/6Kt6KX9zQy0ZjqGbQY7ywCAp2vlqUZdrh1lD
b+qDEnsI6fcN3alPMVmm6apInILbWw==
=jZDq
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.1.2-1 (source) into unstable

2017-10-15 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 14 Oct 2017 17:32:11 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.1.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.1.2-1) unstable; urgency=medium
 .
   * New upstream version 5.1.2
   * Refresh upstream changelog
   * Update to antlr.js new path
   * Update Standards-Version to 4.1.1
Checksums-Sha1:
 294ba9239d12b17b4889abe701675cefefa6b08f 1753 mozilla-noscript_5.1.2-1.dsc
 7ff8b1e6b9816ed954d7f11d79ad43b7b8b6c64b 486240 
mozilla-noscript_5.1.2.orig.tar.xz
 eece28b8e35137b4522507289a9b26034f909cab 130708 
mozilla-noscript_5.1.2-1.debian.tar.xz
Checksums-Sha256:
 867f5aaa7f7dc4490f151d2090fbcbaf1aacbd57ea8cd92e1ccda5cb0025dad2 1753 
mozilla-noscript_5.1.2-1.dsc
 48fa1ccdfcadd464542094536a8a2e7bf285bc974c0bd0972e611d03730a9b19 486240 
mozilla-noscript_5.1.2.orig.tar.xz
 d15cba279ad8d90df980a8f5ebfd5149e86967be2d747d9d3ef06dee848acb52 130708 
mozilla-noscript_5.1.2-1.debian.tar.xz
Files:
 436474dc070a43ee4d86c16243688213 1753 web optional mozilla-noscript_5.1.2-1.dsc
 4ee6b6346d1500d6859a7d1811c38edc 486240 web optional 
mozilla-noscript_5.1.2.orig.tar.xz
 9c0472ac8c7e9a66979ef50c6b418093 130708 web optional 
mozilla-noscript_5.1.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlni4woACgkQBYwc+UT2
vTzMJAf9HhblvmqpCKya+sGSi99rcPlZIR+J0n6MhOfcp8gCu0Mxkjb4MtNslm7d
LAhzf6MheutqGVPIH0xtIt1H+KAknnPRWeZ2nxy9vA/u8dTpMfoQe/MAZm12dN3D
Vf2RFOL7m0i4bbXyywmcgecuRY+ToFWLimik+MQWilyBd9/Lr74LRtMqVYCuanj2
bDqSHCVqXTIT9tYDYllEhoJpwDETrpBwyy/ttW+XzOEihsuVb2qzoVUOSSwuiD4r
oBFcOKokG4xomWhBqFlQeImI0bnB9d/aEkke1EhdHuHl6SATAm7RVc6U+xu4EYMG
lB0yim2ahZhD6OHhK5yFOVSAVT8i9w==
=vlrl
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.0.10-1 (source) into unstable

2017-09-12 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 12 Sep 2017 11:21:25 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.0.10-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.0.10-1) unstable; urgency=medium
 .
   * New upstream version 5.0.10
   * Refresh upstream changelog
Checksums-Sha1:
 13c7069683d5a0b89c9e42c06a9f19bbfd27146f 1760 mozilla-noscript_5.0.10-1.dsc
 985cec8410ff75ad792a716cfeab72b47e10a636 469456 
mozilla-noscript_5.0.10.orig.tar.xz
 01f8fe2e4d9074a152a94570b4f3f813105ec122 130256 
mozilla-noscript_5.0.10-1.debian.tar.xz
Checksums-Sha256:
 6c7ee13d4bb5b133117c9a5de3cbadd98c33032776a3e7f6973142e59b1655d1 1760 
mozilla-noscript_5.0.10-1.dsc
 dfac176568ce80df7c607d8497216e9601dc06a1db429dd5496b098b0b09238b 469456 
mozilla-noscript_5.0.10.orig.tar.xz
 ab40a5502e0ba4258f15f31c329de6fde99615fa98e411905605d03e9ea6bc39 130256 
mozilla-noscript_5.0.10-1.debian.tar.xz
Files:
 c5fb221a29adb781ae8088a448532563 1760 web optional 
mozilla-noscript_5.0.10-1.dsc
 e97eb055b4611d4f69f5a6149add5e64 469456 web optional 
mozilla-noscript_5.0.10.orig.tar.xz
 09359a580b3c02256c3d20bb48f99bff 130256 web optional 
mozilla-noscript_5.0.10-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlm4UZwACgkQBYwc+UT2
vTzv0wf/RE7M7mCrSGRSA2tvrBaWft7lDEQoyMRfWUmFZFuOeNl9do4vhZ5G/8kq
Xay4imC1EJcoihUgxlbSNN1QFGXJvGleYvsdE9PdFazirDwyYVebccFW1bU0ETcn
WSIYPSdq+XCU3/oN3G7b2K0/xmt3Fstqe61SBwjr4J4mhxV6TsKO4OMTtMIeGAIJ
WY3yo/DWjtHKRbOqQQp3LkvdaSNms6WWIRPmA2OOblQseEUzGz1qW4kVnWaWkvrq
yYwnihBPDT94UMP8B3GLp7S+RGjZZ9oRgsCePTmvM81PO1vDl0wYUdOe98Hi9bZd
QOepyUjN0A6TQG1WJU4mA/HAGCXzjQ==
=OApZ
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.0.9-1 (source) into unstable

2017-08-22 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 22 Aug 2017 10:50:33 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.0.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (5.0.9-1) unstable; urgency=medium
 .
   * Fix bug number in previous changelog entry
   * New upstream version 5.0.9
   * Update Standards-Version to 4.1.0
   * Refresh upstream changelog
Checksums-Sha1:
 2752b2974869c913a7a4866c42cfc2e61a3edbfb 1753 mozilla-noscript_5.0.9-1.dsc
 db50c3b9917b59bf86a1f3df60716d9bc343a851 468948 
mozilla-noscript_5.0.9.orig.tar.xz
 21ba3abcc2b10bbe2e18418c67c1016ce16697b9 130028 
mozilla-noscript_5.0.9-1.debian.tar.xz
Checksums-Sha256:
 90b2857f95fb990f82e468419f3bc57e061f866a312bef34651485110f2ee190 1753 
mozilla-noscript_5.0.9-1.dsc
 3eeec83beec0da86bbff1662e6248fce9cdebf24be1010e2b8b870fb71248f84 468948 
mozilla-noscript_5.0.9.orig.tar.xz
 fe7d20b2a2005999c8668093114a51024fdb3dd26e1729cca2cfe9043467ba44 130028 
mozilla-noscript_5.0.9-1.debian.tar.xz
Files:
 29534aef4f96fd4ae2d32ebcf108f27c 1753 web optional mozilla-noscript_5.0.9-1.dsc
 4bf140caf228c69820833b9bc9811eba 468948 web optional 
mozilla-noscript_5.0.9.orig.tar.xz
 c216c6c596df6d9db4c785cd899172a5 130028 web optional 
mozilla-noscript_5.0.9-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlmcmrUACgkQBYwc+UT2
vTxfFwf9Fn7jsH0gbsburIAA+fRrE7KXKoq2tHFKWy9EcpkpXzlwNVfZer+zzZqj
n3rbtQ6ljHeujUi/jYT689ZYEhil8xgrXIJZ9Oig+KlV+3Gj4asMsY68NfAYQW4B
IVUwaCnibFzHxeWZBSX2ICR+R9K3gxbjN2czMFmVMu9nY5gyXeQHCMiRgUa2UfPI
CBCDMhzX9nHmJC8yALF+ijC5iBxF6p3jcCQDuM5dsqiiweXe3W8wfRIQ+m91WACH
INjyuxSBtQ/kz3M8llmTRJtjvgwxlOGVcftEyvvGZfv5Ap1I/DtHb6/mJ2rpp+l6
kx4jma+Nw3u/pHq+NO+KN71l8NOF1g==
=kkeN
-END PGP SIGNATURE-



Accepted mozilla-noscript 5.0.8.1-1 (source) into unstable

2017-08-05 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 05 Aug 2017 11:42:03 -0400
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 5.0.8.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Closes: 866182
Changes:
 mozilla-noscript (5.0.8.1-1) unstable; urgency=medium
 .
   * New upstream version 5.0.8.1 (Closes: #866182)
   * Refresh upstream changelog
   * Update Standards-Version to 4.0.0
Checksums-Sha1:
 6332d8bf51e0f55da11364beb6c2dca84bc07473 1767 mozilla-noscript_5.0.8.1-1.dsc
 9d6b1a2a866a5e344947d4f6bbd07312ab2d1da8 438724 
mozilla-noscript_5.0.8.1.orig.tar.xz
 fe676f9203121267c38a9fcace125076a2066993 129808 
mozilla-noscript_5.0.8.1-1.debian.tar.xz
Checksums-Sha256:
 5e9191d83ba6139cd83a30d6bfed996bcb78579815ba7654874abab96ee23a48 1767 
mozilla-noscript_5.0.8.1-1.dsc
 cc02b385174d99470c382924a4de781eb52ecd4d006f2b6c3ae1520c3dece264 438724 
mozilla-noscript_5.0.8.1.orig.tar.xz
 860d79a87a685d418b65d79a37c2320355844630a843fcc14f6fc6eb2f814cba 129808 
mozilla-noscript_5.0.8.1-1.debian.tar.xz
Files:
 1a1103733eac2dcddc2ee51feaa8c0d6 1767 web optional 
mozilla-noscript_5.0.8.1-1.dsc
 41539a85fc198a7ae382d103a279d8af 438724 web optional 
mozilla-noscript_5.0.8.1.orig.tar.xz
 1f7b65b61bf977e2bfd0cbcaf84e0676 129808 web optional 
mozilla-noscript_5.0.8.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeHVNB7wJXHRI941mBYwc+UT2vTwFAlmGB/8ACgkQBYwc+UT2
vTyUmAf/fvnoyywhSBeWC70BYtZgKXfhMq5thWtIbPVM+iblNE+eqSvu/GTYOd5t
N4qBpR3SeFsrLCC6ZgFV4hfiBGT0pHjLPnAH8s19ZWe9EHmmbsYVuXJ6WMoZFZEt
2COEdDCcPqjYQTE21VvlQqK/iC+OFHbWv5liMNhUKkDT0GRxZfqm+5aLNzbexQuO
1g569HGaWhdNde3qGZBR93uGxd2ZeJmGviVz7MuSVtgP10MDAIlUq1d+zu9mknFf
rzBLVZuddqQwDkBgNj554v7IkI8eNnPt5neVEb9ObyfW4G0saw5l57sG0E+bCPZy
zIrcdrUJbgkvbL7JgBPeATlvU7efjQ==
=1shD
-END PGP SIGNATURE-



Accepted mozilla-password-editor 2.10.3-1 (source) into unstable

2017-01-15 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 15 Jan 2017 14:00:10 +0100
Source: mozilla-password-editor
Binary: xul-ext-password-editor
Architecture: source
Version: 2.10.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 xul-ext-password-editor - edit password manager entries in Mozilla applications
Changes:
 mozilla-password-editor (2.10.3-1) unstable; urgency=medium
 .
   * New upstream release.
Checksums-Sha1:
 2535e08fb5f3f9652d5010936bff8f91988ab7d6 2164 
mozilla-password-editor_2.10.3-1.dsc
 5a0b82d41ed241a974d091fd859402d7f558c79c 151843 
mozilla-password-editor_2.10.3.orig.tar.gz
 b04239b966e170cd64ae1539e0ed8e56060526b8 11008 
mozilla-password-editor_2.10.3-1.debian.tar.xz
Checksums-Sha256:
 2675d61ae1e11d6c1f23d889a0deec032de445dc5999cd97dfea21a52cbcd9c2 2164 
mozilla-password-editor_2.10.3-1.dsc
 85d60a3c0f246174a0f0e189c48701eba99f264b9230cd1fd64a0d20aaa86482 151843 
mozilla-password-editor_2.10.3.orig.tar.gz
 a8cd3282fcedbf255cac3848cbce65b4b350d05ee49218191e4a987cc3d03a89 11008 
mozilla-password-editor_2.10.3-1.debian.tar.xz
Files:
 c59e96ad6a352078ce3031d02af3f817 2164 web optional 
mozilla-password-editor_2.10.3-1.dsc
 501ac6fddef85df7e511855c12f32798 151843 web optional 
mozilla-password-editor_2.10.3.orig.tar.gz
 b2e80a389276fc7e923cfb0eb13a49e0 11008 web optional 
mozilla-password-editor_2.10.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAlh7dIYACgkQCBa54Yx2
K61ppA//T3EnHkh4VU/d6wu2tvNgZi3gadmBP3TdZT1foWQDq804YJ2TsE8fNM+x
ikX/uZq7bUx/9DxpXukaNHmQDFzW0cmccw1hEoP9/Pvw/EDieL5Xa1cJInnRv86r
hwhu6djRtWHbqBRm3zS1TToPoWCPoiHfKzjTZLmsHjnZ9V5ufHbG87ihlD2H3Jl4
oafQvKHnQw40uH6e9ScB2KHWlTFQ1eAqds08JMvWXOZXYqWmT/sLvJ+TUxBmo1SC
WTZLjtEZcKc6EgDjHtD2W4z0dqJtfyf0OlBsaUUaLG5/CCpdRItSeFH1cYvvYUep
RRGPLmzmJoqsG/13RlkRYdEuaOpSGYynU1MTm382cIykUMxZ4yXfV0yMZzVURPVp
wqPghR6HcbQumztLOAp+all87sY8V1++RBdqqLC3mk/kYar2MMLKSuLYsmZBQIUJ
yirgBtd0HzhE+UNNGXynYNoaKjm/wWNZFzmF79Gx6hus3zBq+0me7Q1A9eXgXAcg
v/BEfmuNf/+2OUdDdOBf2/pl/C5DcgGNzAD5cxqNNQ5Lyzf/YJOaPUEGbxsa9Hds
PSvixd4C94Kd487XLrY77uH3BdODk2wu/q0icjYxafRjd3efVHrlGhKDc7PwKFSi
x/mtNKNhn+WmqnLUt9/sRBjRVvR5LpbqRYk/Djrytz10iXJt/k8=
=ZXue
-END PGP SIGNATURE-



Accepted mozilla-noscript 2.9.0.14-1 (source) into unstable

2016-10-31 Thread David Prévot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 31 Oct 2016 15:12:24 -1000
Source: mozilla-noscript
Binary: xul-ext-noscript
Architecture: source
Version: 2.9.0.14-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Mozilla Extension Maintainers 
<pkg-mozext-maintain...@lists.alioth.debian.org>
Changed-By: David Prévot <taf...@debian.org>
Description:
 xul-ext-noscript - permissions manager for Firefox
Changes:
 mozilla-noscript (2.9.0.14-1) unstable; urgency=medium
 .
   * New upstream version 2.9.0.14
   * Refresh upstream changelog
   * Update Standards-Version to 3.9.8
Checksums-Sha1:
 e586bd3f5a00846ad2f594a2b147f1588b72bc22 1741 mozilla-noscript_2.9.0.14-1.dsc
 10bfba22fa8060e028d2e4e227581f7a696594a3 442756 
mozilla-noscript_2.9.0.14.orig.tar.xz
 f3d08b09f14c585f7fe8517447ce0f6a6f39989e 126904 
mozilla-noscript_2.9.0.14-1.debian.tar.xz
Checksums-Sha256:
 c84ac118097a8557de3bcb65dc4b0e0e52bb8b1d46e1f80761dba93847b82b8c 1741 
mozilla-noscript_2.9.0.14-1.dsc
 4e8a9f00234b825bf387f668caa1d6f2dd0d9c3658c00071bc442b82a368916d 442756 
mozilla-noscript_2.9.0.14.orig.tar.xz
 b6a6702fd822b9b9a09108ed2dd988cdd8854c1cc263f80d17e4ffdeaf95c578 126904 
mozilla-noscript_2.9.0.14-1.debian.tar.xz
Files:
 a6348616f44a9a9bd906eef90daaa518 1741 web optional 
mozilla-noscript_2.9.0.14-1.dsc
 2a7a4d15b93f98a892cd99124651b7dc 442756 web optional 
mozilla-noscript_2.9.0.14.orig.tar.xz
 7ff3a1871cf00c570a180b2456209c00 126904 web optional 
mozilla-noscript_2.9.0.14-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYGAKzAAoJEAWMHPlE9r08GSAH/jcGErFYTeP5X/S5T/y2JdmC
6SWCV8H4TbY05bPE+5j1sKgsZiQGH7cHbsWXd4XW+T00CRegjw6rQhxvQa7bGNbs
UO04YbTL30URkra95gw+yLK8C5JpglytFYh+UkLXcllbejojpQWFI3LYRil74sew
i7zvFCCHUpuyiGoRj8l8Vg8XuAUSov109PEUCDO0rqcd7oK/CQ/tAXz3IfTQKKMt
NafYl3gZcPZDYjfpKtxA+ShGetivz91EU2xgFXa/Yu0n71q1yTei2cJgOTOBWXs/
u417sSxJ9xdOf5+e9n9ZoeVGn3zk/fb5xq0EyE/vd6FDb1sg+kb5XYJsXREkFVM=
=ud3/
-END PGP SIGNATURE-



Accepted mozilla-gnome-keyring 0.12-1 (source) into unstable

2016-09-25 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 25 Sep 2016 13:03:19 +0200
Source: mozilla-gnome-keyring
Binary: xul-ext-gnome-keyring
Architecture: source
Version: 0.12-1
Distribution: unstable
Urgency: medium
Maintainer: Ximin Luo <infini...@debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 xul-ext-gnome-keyring - Store mozilla passwords in GNOME Keyring
Closes: 838546
Changes:
 mozilla-gnome-keyring (0.12-1) unstable; urgency=medium
 .
   * New upstream release. (Closes: #838546)
Checksums-Sha1:
 0f373fa127eef9bd2b2e4d8f6550c793cfa0f186 2011 mozilla-gnome-keyring_0.12-1.dsc
 202ded504ceed1ac4094c878df8a2140c5e1ef76 28928 
mozilla-gnome-keyring_0.12.orig.tar.gz
 eacd52b782e5ade05c94bfbf70dc4638f3b10732 2672 
mozilla-gnome-keyring_0.12-1.debian.tar.xz
Checksums-Sha256:
 64e84da14297a29c55e543fdfa18fe0a6c985bb3c9605618ab8ab2e0ebfc6080 2011 
mozilla-gnome-keyring_0.12-1.dsc
 d70923c89646fa88b5cd3d3d0395720e1cb85bc6fd9e2c9e61c370682e4361c7 28928 
mozilla-gnome-keyring_0.12.orig.tar.gz
 76679166db3b2a1fd3f2de05a164c59bdd0f446361124d79d35ee46ca9453aa1 2672 
mozilla-gnome-keyring_0.12-1.debian.tar.xz
Files:
 296251ea21b73e1e781e5e1d68696d2c 2011 web optional 
mozilla-gnome-keyring_0.12-1.dsc
 2d01fc9bc4c39abdf1aef795b5d163ea 28928 web optional 
mozilla-gnome-keyring_0.12.orig.tar.gz
 dba07f570cff8417018fee7853cb2bc9 2672 web optional 
mozilla-gnome-keyring_0.12-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJX568cAAoJEIYN7zuPZQt5n+YP/1Ku1WFFtdIbBLM2Vfzf9FX8
8h623x5G8bBYq0fbGKHR3ABSV2ZjndibIJYAvJ/qGR189rK8hfx9f0wY7MtQ5+/0
L1XJM3DZ+oXfEjRr0+hVK+/jQzCTcqH7B4gJdONDSG1sUaCtVHrRy0YGz6n2cN6t
sVFTcgO2k4fo6bBefQuLFzj35Ujeq9KjJ8tFufoxuQ3m1GoCTO6/LhrmMx20XOqF
UDHcJrH0cEIqJmG6FEmyPdp9JqcSMnPt0/YDxjigzlBTI5pZvWfZX6RG4gSaJ/Mb
IFwBozzg/U2HekDfKnoZur0U0b4bleODjfkDpHEkD9fNA8G8zpTbCj3bqZAI7e5i
ogDIDLfDxElIwT9LVOMLZzoHc3CjmgtPDKMdGDL+VnYfVrbVdHNZl7JGv+4Qf7V/
XOoCTlerSE5hmvIHZuKYzMfSiTk2vEp7rXjKy7ayRuYk8Xy9AnvpomumskUE6/98
a+WYE5CbRxROmPfymFgaNxVOl+XtcQEYqklgOdF5xj/Usj5PZ9qhcjhGKi/p7DXC
Ny3g6c5ajcsIiIip1dEAihoTnPtZkvPBCr/YSo/q0H3+YDRwkFon8vBmko1TLuZb
hc4/71VpJjHy63bX3YE0BhGaMEZu1iKs+SlcaweQbJr4FPcfBaHmnSmvWkp1XDEM
4eKBb63CD6gbscvGvam0
=64Vi
-END PGP SIGNATURE-



Accepted mozilla-gnome-keyring 0.11+git4-3 (source all) into unstable, unstable

2016-09-24 Thread Ximin Luo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 24 Sep 2016 11:29:52 +0200
Source: mozilla-gnome-keyring
Binary: xul-ext-gnome-keyring
Architecture: source all
Version: 0.11+git4-3
Distribution: unstable
Urgency: medium
Maintainer: Ximin Luo <infini...@debian.org>
Changed-By: Ximin Luo <infini...@debian.org>
Description:
 xul-ext-gnome-keyring - Store mozilla passwords in GNOME Keyring
Closes: 838746
Changes:
 mozilla-gnome-keyring (0.11+git4-3) unstable; urgency=medium
 .
   * Set maxVersion to 999. (Closes: #838746)
Checksums-Sha1:
 76125d5b5e0f49c62d9237ec62f56c5c15451a27 2046 
mozilla-gnome-keyring_0.11+git4-3.dsc
 dafe0c3bcba32036c6f097f8616b803ffca78b4b 2660 
mozilla-gnome-keyring_0.11+git4-3.debian.tar.xz
 607b1b6cd2d1ab897cfa8b1a1003cf587334f340 15454 
xul-ext-gnome-keyring_0.11+git4-3_all.deb
Checksums-Sha256:
 fc7a56902b7d37390c3f2b8857b67f2abb572b090dc72aee932b3fcd695476a5 2046 
mozilla-gnome-keyring_0.11+git4-3.dsc
 5846b99c3704abc0c9024d22cfc221c66a6c5bf5b8e7b2a2dcc6c1938771a32b 2660 
mozilla-gnome-keyring_0.11+git4-3.debian.tar.xz
 0a89c9e5ff8a30cf700da6c6c40db2aa8395189fc958bbcdd4708ae780263321 15454 
xul-ext-gnome-keyring_0.11+git4-3_all.deb
Files:
 874207f628470022f938685befbc6c07 2046 web optional 
mozilla-gnome-keyring_0.11+git4-3.dsc
 993c6ac1bb72ff96553e86465af3165f 2660 web optional 
mozilla-gnome-keyring_0.11+git4-3.debian.tar.xz
 7545b1c1a673a2b4247e2c6a18b89885 15454 web optional 
xul-ext-gnome-keyring_0.11+git4-3_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJX5lP5AAoJEIYN7zuPZQt5/SUP/2XVpqTQwdxrWTLyqgvM6JG4
F0nM9ELegKeOzrhnETMqOr26BXiUTmqjhfAH16/4aOjJ/sjOP5+R73GuectdOqNL
XeTIBtuWHjwUl6bQ721XeaJJnTjMBRZJ24HSETSLEe0Ul/hii3QVw3TLN4DaPYuU
q5r8VKloCE7dYsDE2Lr56PGdo1iiFTrvXGE47DNuvDHjUY894Y/i252evJMp5e9u
lmE9P4wNOfwVSLUAWD/oKWGya3x7F2Swh8Fo41JVtX6YSPypq6ILvQ6gsbjw13aM
nUuvGXCaBLRgjqSO5NBCjV3ir/84L/zRw8DDJNRnUY1+YTBGboq/+g6HOyIbs3Ri
/BCD+vNFvKGf+sDvh39W07hqmqnGGz96u4wHwOThfZWCByjZwh45sGXbVlTxylhA
i+OxMmhRrAYgWMAMgW6HFWTDJZ9V5+9PJaPeTn573KC+SvkNQwcm3YTXg53l/3N6
zAnb5fi/RVLp6Z4q6/G+YolfLvi3VpwsXqQKvW08nDI6mB3dl8EucGRawUdPs4mR
KIytYWa4sb3Jo+4gNZPUs3+n+2Wk2eFsMpjjw30ucceF0MVzPelklbujDPRXbCJR
tNBE7jqhjMmtAtGAPsTj0GVcjQjBtjDjdLBxOdeQoXwVkpIp3Tq6l/YzAUe60ADO
ihOeXL0q5UDlIPm2ycJa
=Vapo
-END PGP SIGNATURE-



  1   2   3   4   5   6   7   8   9   10   >