Re: The sec-approval process makes users safer

On 9/10/19 3:53 PM, Daniel Veditz wrote: Other groups must be using that flag also Sure, it just means "this needs a test checked in". "Only" 718 fixed bugs with a sec- keyword have that flag. A mere trifle! ;) -Boris ___ dev-platform mailing li

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Hello, the use case is: A WebDAV (CalDAV/CardDAV) server offers: * calendars for authenticated users * calendars for unauthenticated users * the bootstrapping procedure described in RFC 6764. So the server returns one set of availabe calendars (caldav collections) for unauthenticated user, and a

Re: The sec-approval process makes users safer

On Tue, Sep 10, 2019 at 9:35 AM Boris Zbarsky wrote: > On 9/10/19 12:30 PM, Boris Zbarsky wrote: > > I just checked, and there are currently 826 bugs that have > > "in-testsuite?" set on them where I am the flag requester. > > And overall there seem to be ~7300 bugs that have that flag set. > Ot

Re: The sec-approval process makes users safer

On 9/10/19 12:30 PM, Boris Zbarsky wrote: I just checked, and there are currently 826 bugs that have "in-testsuite?" set on them where I am the flag requester. And overall there seem to be ~7300 bugs that have that flag set. -Boris ___ dev-platform m

Re: The sec-approval process makes users safer

On 9/10/19 12:16 PM, Dan Mosedale wrote: Seems like it ought to be straightforward to do something to cause in-testsuite? flags to send mail occasionally, or show up on some dashboard, or... Could be worth it. I just checked, and there are currently 826 bugs that have "in-testsuite?" set on t

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

There is no official or standardized way to "force" authentication, because this is really a non-standard thing you do. I would more suggest a login request path like "https://foo.com/login.php"; or whatever scripting is used, that would return 401 with the challenge response header. Authentic

Re: The sec-approval process makes users safer

Seems like it ought to be straightforward to do something to cause in-testsuite? flags to send mail occasionally, or show up on some dashboard, or... Dan Am Di., 10. Sept. 2019 um 09:11 Uhr schrieb Andrew McCreight : > > On Tue, Sep 10, 2019 at 4:55 PM Dave Townsend wrote: > > > On Mon, Sep 9, 2

Re: The sec-approval process makes users safer

On Tue, Sep 10, 2019 at 4:55 PM Dave Townsend wrote: > On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote: > > > Those of you longer in the tooth may remember Firefox was successfully > > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix > it. > > We already had -- in the Fire

Re: The sec-approval process makes users safer

On 9/10/19 7:55 AM, Dave Townsend wrote: > How often do we go back and land those tests and comments after the fix has > been in the release builds for a suitable amount of time? I always land my tests...at some point. I don't know if everyone else adequately remembers to do so. We don't forma

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Alternatively, the admin wants me to send a bogus authenticate header, like Authenticate: X to trigger the authentication. I really do not like that. Maybe I can get him to jump into the discussion. ___ dev-platform mailing list dev-platform@lists.mozi

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

No, the server is not controlled by me. The admin expects clients to send a Basic Auth header without having seen the WWW-Authenticate header, if I do not want to access the resource unauthenticated. For me this looked wrong from the beginning, but just wanted to make sure I am not missing anyt

Re: The sec-approval process makes users safer

On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote: > Those of you longer in the tooth may remember Firefox was successfully > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it. > We already had -- in the Firefox release shipping days later. 🤦 > > https://bugzilla.mozilla.o

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

On 2019-09-10 15:45, john.bieling--- via dev-platform wrote: Thanks for your reply. I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Thanks for your reply. I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for me). I was hoping there was some established mechanism to f

Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests

Hi, adding a custom `Authentication` request header is the right way to do this.  Not sure what you mean by "I want nsIHttpChannel to do all the auth stuff" when it doesn't know it has to authenticate to the site.  We need a 401 response to produce and cache `Authentication` request headers b

Authentication strategy for servers, which do not return a 401 on unauthenticated requests

nsIHttpChannel is usually doing an unauthenticated request to a remote URL to get the WWW-Authentication header from the 401 response and then pick one of the allowed methods to authenticate. I am running into an issue, where the server is not returning a 401 but actually returns a result for a

Recent ESLint updates - BigInt, improved autofixing and more

Over the last couple of weeks we landed a couple of ESLint updates which support new features and fix a few issues. Here's a quick summary: * BigInt is now supported. * For globals defined via /* global

Re: The sec-approval process makes users safer

Hi Jeff, thank you for bringing this up! Halvar Flake (also formerly of P0) argues here that committing a patch is not very different from committing the test case: Which is not something I'm willing to believe in totality. I thi