CSP

https://w3c.github.io/webappsec/specs/CSP2/
@slightlyoff has thoughts on a reflective API

Discussed in SF; @slightlyoff TBD.

Discussed at Berlin f2f: Alex: Webappsec in process of formalizing CSP level 2 (renamed from 1.1). We should reengage once they have CSP 2 out the door.

Current plan is to republish http://www.w3.org/TR/CSP2/ as a CR to deal with something we had to remove, then proceed to PR and eventually REC.
I plan to kick off CSP3 (again) this quarter. Hope that actually happens.

Edited OP to point to new CSP2 URL

Discussed at Boston f2f : https://pad.w3ctag.org/p/09-15-2015-minutes

CSP Issues list here: https://github.com/w3c/webappsec/milestones/CSP 3

@mnot prepare thoughts around improving release speed and/or modularity of CSP3 for a TPAC discussion.

I am curious about these ideas, and would like to hear more. :)

@mikewest - People are just noticing that the monolithic nature of CSP releases is in some ways hurting adoption; people (wrongly or rightly) feel they need to implement the entire version, and users feel they have to understand the entire new spec before using it.
Getting new features onto a release train can be frustrating too (e.g., cookie-scope)
Also, giving a new major version number to it when it contains compatible changes confuses many.
No concrete suggestions, but one straw-man would be to make the major versions of CSP only come out when there's a breaking change, and to allow other specs to define extensions.

@mikewest - another CSP issue worth talking about again is the delivery mechanism. When I look at sites like Twitter, who have really long CSP headers:
https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Fmnot&req_hdr=User-Agent%3AMozilla%2F5.0+(X11%3B+U%3B+Linux+x86_64%3B+en-US)+Gecko+Firefox%2F3.0.8
... it makes me think we can do better (especially considering that this will consume most of the compression context in HTTP/2 -- 4k -- meaning it'll make header compression really inefficient).
I've been noodling on a mechanism to allow a site to put its policies in a .well-known location and then refer to them by a token in responses when the client indicates it's fetched that location; would you care to look at a straw-spec?

@mnot, @travisleithead, @hillbrad: I've been thinking about a modular CSP myself, actually. I do think it's a good idea ("CSP Core" + smaller specs), though I'm not entirely sure where the lines are. For instance, I started on https://w3c.github.io/webappsec/specs/csp-cookies/ this afternoon to chat about (and because it's ~2 years late). Is that enough to stand on its own? I don't know. UPGRADE was, but it was significantly more complex. shrug Let's talk about it at TPAC, I guess?
@mnot: 1. Twitter's policy is huge. 2. I have a pinning proposal I haven't touched in ~6 months (https://w3c.github.io/webappsec/specs/csp-pinning/), and some of the discussion pointed in the direction of a manifest. Maybe HTTP/2 push solves the latency problems associated with a blocking request that I've always pushed back on in the WG? I'd be interested in the strawspec (but would prefer discussing it in an issue on w3c/webappsec if possible. :)

I took a quick look at https://w3c.github.io/webappsec/specs/csp-cookies/ and while it is small, I am drawn to smaller, easier-to-digest documents. So IMO, this smaller-spec works well.
The risk, as you note, is finding the right place to draw the lines that decreases the interdependencies between the docs. I'd have to spend more time understanding the larger CSP doc to have an intuition on whether the current divide is good. Ultimately though, you probably know best :)

+1 here as well -- seems like an encouraging direction, but like travis says, will require some careful oversight.

Oversight... oversight... If only I could find some group that concerns itself with architectural technologisms to provide some adult supervision while we work through that discussion. :)

I meant oversight by people who actually know about CSP :)

@mikewest - I don't see how CSP Pinning helps, because a server doesn't know when it's safe to omit CSP headers for any give request.
Anyway, I owe you a straw-man proposal, I think...

Hello, lovely TAGians. https://w3c.github.io/webappsec-csp/ is far enough along that I'd appreciate some feeback from y'all about the integration points between CSP, HTML, and Fetch, as well as the hooks I've built in for extensibility. Happy to chat with anyone who's interested, on a call or via email/GitHub/whatever. :)

Thanks, @mikewest. I've put it on the agenda for this week's call and hopefully we can get you some useful feedback soon.

Discussed briefly at Melbourne; will still review.

Hey Mike,
Overall this looks like a reasonable evolution for CSP; switching to fetch seems very sane.
The extensibility also looks reasonable. It's good to see that there are multiple implementations of the full level 2 spec (at least according to caniuse; is that correct?); it'd be even better to see Firefox get up to speed...
I'm still concerned about the overall size of CSP headers, as well as its uptake by sites. I think there may be a much bigger discussion of what our stance to securing the Web should be lurking in that latter point, but that shouldn't hold this up.
One nit - You need to update the IANA registry entries for all of the affected directives in the IANA Considerations section.

discussed in telecon 1 june 2016 https://github.com/w3ctag/meetings/blob/gh-pages/2016/telecons/06-01-agenda.md

@mikewest we've discussed that and the TAG likes the direction you're going in; we don't have any substantial architectural comment, beyond saying that CSP 3 looks like a good evolution, modularity looks about right, and using Fetch is sane.


Double underscore instead of dots

Hi, I would like to request using the option to use double underscore "__" instead of dots "."
The need comes from flattening dotnet appsettings.json files where "__" is used instead of dots.
Example:
  "Logging__LogLevel__Microsoft": "Debug",
  "Logging__LogLevel__Default": "Debug",

Kind regards, Geir

@geirivarjerstad I haven't done any dotnet work in years; is the file in question always appsettings.json? Or would there be other cases for assuming __ rather than .?  I'm trying to determine how to know when to assume __ rather than . for the separator, without creating separate commands.

Sorry @geirivarjerstad  I misunderstood; I'm still thinking about unflatten.  I believe your request is actually to change the output to use __ as the generated separator, not to recognize it on input (unflatten).
I think we'll need a separate command for that although it could auto-recognize appsettings.json specifically and behave differently for that one filename. But it seems inappropriate though to reserve a specific filename, so a separate VS Code command is probably best.

I have released a 1.0.6 version (available now at https://marketplace.visualstudio.com/items?itemName=Appurist.json-flattener)  that includes a 5th command, a "Flatten (Selection - dotnet__separator)" with an id of appurist.json-flattener.selection-dotnet which you can find with Ctrl-Shift-P as usual. Update and this command should allow you to select json text in an editor and convert it to the flattened format with dotnet __ separators.
Feel free to comment or reopen if this isn't quite what this Issue was looking for.


Test Issue created at Sat, 05 Feb 2022 02:11:57 GMT

Test issue body  Sat, 05 Feb 2022 02:11:57 GMT

Comment on issue at Sat, 05 Feb 2022 02:11:59 GMT


Add data for 8.2.1

8.2.1 remains to be ported over to Open SDG hub. Will be closed upon merging of #99

Closed #99

Please review and confirm methodology as per Request_Indicators_2022_XLSX file in data gap folder

done in https://github.com/sdg-data-canada-odd-donnees/sdg-data-donnees-odd/commit/61042e44368c568bcef5df5f9c51b686fa235eff
methodology was correct but old GIF previously reported indicator using constant dollars, rather than chained


gh-r installation of direnv fails on ubuntu aarch64

Describe the bug
Running Ubuntu 20.04 on Raspberry PI 3, which is aarch64 machine type, the i386 github release of direnv is downloaded.
https://github.com/direnv/direnv/releases
To Reproduce
configure:
zinit ice from"gh-r" as"program" mv"direnv* -> direnv" atclone'./direnv hook zsh > zhook.zsh' atpull'%atclone' pick"direnv" src"zhook.zsh"
zinit light direnv/direnv

install:
Downloading direnv/direnv... (as direnv/direnv...)
(Requesting `direnv.linux-386'...)
ziextract: Successfully extracted and assigned +x chmod to the file: `direnv.linux-386'.
renamed 'direnv.linux-386' -> 'direnv'
(eval):1: exec format error: ./direnv

Expected behavior
I expect it to install an arm-compatible version of direnv.
Downloading direnv/direnv... (as direnv/direnv...)
(Requesting `direnv.linux-arm'...)
ziextract: Successfully extracted and assigned +x chmod to the file: `direnv.linux-arm'.
renamed 'direnv.linux-arm' -> 'direnv'

Screenshots
N/A
Versions:

$ZSH_VERSION == zsh 5.8 (aarch64-unknown-linux-gnu)
Operating system name and version (uname -a): Linux pi-solar 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

Additional context
Adding arm to https://github.com/zdharma/zinit/blob/ff12246fb49b6a3e1ae274e5fb9b0508ab892f75/zinit-install.zsh#L1450 allows it to succeed. Though in the case of direnv I'm guessing this arm release will work on any arm architecture.

It should be fixed, thanks.

Thank you!

This fix did not work for junegunn/fzf-bin unfortunately. In this case there are arm releases for v5-v8 and it needs to pick v8 to succeed. I was able to get it to work by changing aarch64-2 "arm" to aarch64-2 "arm[8]?". I don't know the code well enough to be sure that this fix makes sense but it works for me.


Asymmetric Serialization

In #64, I created test cases to illustrate the problem.  Long story short, I believe it should be possible to PUT the body of a GET to the same endpoint in the default case.  This does not work because drf-hal-json returns a JSON object but (seems to) expect stringified JSON.

Invalid per discussion in #64.


Example Case 8 or 16bit LSTM

Provide a simple example case for an LSTM with fixed point weights of 8 or 16 bit. This should allow us to get the fixed point weights from the model for verifying the hardware implementation in progress. Maybe we can use easily accessible training data from torchaudio? In a later step we could generate the corresponding testbench from that LSTM example already, but that's for a future issue.

@SuperChange001 should be in the loop for this one


finally shutdown executor in AbstractRestore

Finally shutdown executor in AbstractRestore so that Restorer can exit.

NetflixOSS » Priam » Priam-pull-requests #22 FAILURE
Looks like there's a problem with this pull request

Priam-pull-requests #184 FAILURE
Looks like there's a problem with this pull request

Hello,
We will review the pull request.
Thank you