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

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

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

/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

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

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

Suggestion: You should delete Mozilla ESR programs

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)?

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 waiv

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

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 wha

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

, 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)?

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

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

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

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

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

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

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

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

* 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

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

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 wro

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

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

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

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 h

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

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 ag

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

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)?

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 qu

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

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

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

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

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

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 i

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

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 t

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

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 th

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

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

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

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

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

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

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

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 nat

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

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 insis

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

// 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 becaus

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

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

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

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

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

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 di

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

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 jurisdic

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

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

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

ements 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 coo

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

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 >> > [r

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

ussion 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-mak

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

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

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

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

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

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

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

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)?

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

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

k 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)?

eal 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

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

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 >

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

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

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

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 yo

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

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

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

r 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)?

ink 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 th

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

und > 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)?

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

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

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

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

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 AN

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

ght 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

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

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

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

urý 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. > > -- > b

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

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, p

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

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 aga

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

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 bette

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

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

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

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

Mozilla Firefox

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

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

* 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 (deb

Re: Proposition: Insert Mozilla Firefox Release in Debian

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 t

Re: Proposition: Insert Mozilla Firefox Release in Debian

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 reque

Re: Proposition: Insert Mozilla Firefox Release in Debian

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

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

Dear Woman and Man! Please Insert Mozilla Firefox Release in Debian. With kind Greetings!

Re: Bug: can't install Mozilla Firefox

* 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? &g

Bug: can't install Mozilla Firefox

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

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

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

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.

Re: Bug#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

Control: tag -1 wontfix Le jeudi 24 mars 2016 à 15:51:34+0100, Ondřej Surý a écrit : > Are you sure we need this in the archive? Packaging dead horse doesn't seem > like a good idea... > > Wikipedia says: > > It was launched in July 2011, but after failing to ac

Re: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

Are you sure we need this in the archive? Packaging dead horse doesn't seem like a good idea... Wikipedia says: It was launched in July 2011, but after failing to achieve traction, Mozilla announced in January 2016 plans to decommission the service by the end of the year.[3] O. -- O

Re: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

* Pierre-Elliott Bécue [2016-03-23 22:44:18 +0100]: > Control: owner -1 ! > Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID > Protocol (Mozilla Persona) > > Hey, > > I intend to package. VCS is up, the package builds correctly. > > V

ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

Control: owner -1 ! Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona) Hey, I intend to package. VCS is up, the package builds correctly. VCS: https://github.com/P-EB/python-browserid Build results: https://peb.pimeys.fr/packages/python

Bug#805278: ITP: heka -- Stream processing software system developed by Mozilla

Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: heka Version : 0.10.0b1 Upstream Author : Ben Bangert, Mike Trinkala, Rob Miller, Victor Ng, David Birdsong, Michael Gibson * URL : https://github.com/mozill

Bug#802401: ITP: node-ast-types -- Esprima-compatible implementation of the Mozilla JS Parser API

: JavaScript Description : Esprima-compatible implementation of the Mozilla JS Parser API This module provides an efficient, modular and Esprima-compatible implementation of the abstract syntax tree type hierarchy pioneered by the Mozilla Parser API. Cheers, Snark on #debian-js

Bug#741487: ITP: mozjpeg -- Mozilla JPEG Encoder Project

Package: wnpp Severity: wishlist Owner: Pierre Rudloff * Package name: mozjpeg Version : 1.0 Upstream Author : Mozilla * URL : https://github.com/mozilla/mozjpeg * License : Custom free software license Programming Lang: C Description : Mozilla JPEG

Bug#736844: ITP: mozilla-password-editor -- Create and edit entries in the password manager in Mozilla applications

Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: mozilla-password-editor Version : 2.7.2 Upstream Author : Daniel Dawson * URL : https://addons.mozilla.org/en-US/firefox/addon/saved-password-editor/ * License : GPL-3 Programming Lang

Re: Switching to mozilla ESR in stable-security

On 05/28/2013 04:33 PM, Moritz Muehlenhoff wrote: Hi, we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. As such, we'll switch to releasing the ESR releases of iceweasel and icedo

Re: Switching to mozilla ESR in stable-security

; independently of the delivery mechanism. > The main difference would be that we accept the fact that Mozilla > software aren't suitable to stay in the stable Debian, and that we > declare that they can only be sustainable through a repository that has > recent updates. Backports seems a

Re: Switching to mozilla ESR in stable-security

witch to releasing the ESR releases of iceweasel >> and icedove in stable-security.=20 > > Would it be possible to switch to the Mozilla branding in this case? No, that is unrelated. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a

Re: Switching to mozilla ESR in stable-security

On Sun, Jun 02, 2013 at 12:10:56PM +0300, Andrei POPESCU wrote: > On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: > > > > As such, we'll switch to releasing the ESR releases of iceweasel > > and icedove in stable-security. > > Would it be possible to switch

Re: Switching to mozilla ESR in stable-security

much we can do here. We can select a narrow (!) >> set of important addons (e.g. enigmail for Icedove) that we will >> keep in sync through stable-security, but that doesn't scale for >> the full scale of Mozilla extensions currently packaged. >> >> In the fut

Re: Switching to mozilla ESR in stable-security

On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: > > As such, we'll switch to releasing the ESR releases of iceweasel > and icedove in stable-security. Would it be possible to switch to the Mozilla branding in this case? Kind regards, Andrei -- http://wiki.debian.org/FAQs

Re: Switching to mozilla ESR in stable-security

On 06/02/2013 01:35 AM, Florian Weimer wrote: > I'm not sure if moving packages between repositories makes that much > of a difference. Either they work acceptably well, or they don't, > independently of the delivery mechanism. The main difference would be that we accept th

Re: Switching to mozilla ESR in stable-security

current upstream release even in their oldest supported distro) - The ESR releases shipped by Mozilla receive more QA testing than we could possibly provide for our backports. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "un

Re: Switching to mozilla ESR in stable-security

Christoph Anton Mitterer schrieb: > > --=-dGSWlplfgLb+HUgDia6J > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Hi Moritz. > > Moritz Muehlenhoff wrote: >> In the future the majority of packages should thus rather be installed >> through http://addons.m

Re: Switching to mozilla ESR in stable-security

* Thomas Goirand: > Maybe the best way forward is to have backports activated by default > (there's already a patch available for that, not sure if it has been > applied to d-i yet). Then when installing a desktop (since backports > are now fully part of Debian), we could provide browsers from the

Re: Switching to mozilla ESR in stable-security

break with ESR17 > > > and ESR24 in the future. > > > > > > However, there's not much we can do here. We can select a narrow (!) > > > set of important addons (e.g. enigmail for Icedove) that we will > > > keep in sync through stable-security, but th

Re: Switching to mozilla ESR in stable-security

orts, but would not install such software by default. > > Packages which, by the way, are not supported by the security team. Is it important? Doesn't upstream (here, Mozilla) do a good job concerning security? -- Vincent Lefèvre - Web: <http://www.vinc17.net/> 100% accessible vali

Re: Switching to mozilla ESR in stable-security

Quoting Russ Allbery (2013-05-30 19:56:23) > Wouter Verhelst writes: > > On 30-05-13 19:29, Thomas Goirand wrote: > > >> Maybe the best way forward is to have backports activated by > >> default > > > No. > > > If we're going down that route, we might as well give up on doing a > > stable rel

Re: Switching to mozilla ESR in stable-security

Russ Allbery debian.org> writes: [...] > This would *enable* users to install software from backports if it either > didn't exist in stable at all or if they explicitly requested it from > backports, but would not install such software by default. Packages which, by the way, are not supported by

Re: Switching to mozilla ESR in stable-security

Russ Allbery (30/05/2013): > Jonas Smedegaard writes: > > Sorry, what bugreport? > > > I do not consider backports.debian.org of same quality as > > debian.org so am concerned by what you outline above, and would > > like to (at the least) read up on the relevant discussion > > (i.e. avoid rehas

Re: Switching to mozilla ESR in stable-security

r, there's not much we can do here. We can select a narrow (!) > > set of important addons (e.g. enigmail for Icedove) that we will > > keep in sync through stable-security, but that doesn't scale for > > the full scale of Mozilla extensions currently packaged. > > &g

Re: Switching to mozilla ESR in stable-security

On 05/30/2013 08:06 PM, Scott Kitterman wrote: > FWIW, Ubuntu has done this with their backports repositories for the last two > years of releases debian-live images have this by default since squeeze too. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.

Re: Switching to mozilla ESR in stable-security

Jonas Smedegaard writes: > Sorry, what bugreport? > I do not consider backports.debian.org of same quality as debian.org so > am concerned by what you outline above, and would like to (at the least) > read up on the relevant discussion (i.e. avoid rehashing it here). I'm afraid I've expired the

  1   2   3   4   5   >