w3c / webappsec-suborigins

Suborigins
https://w3c.github.io/webappsec-suborigins/
Other
25 stars 9 forks source link

Suborigin names should not be allowed to start with number #47

Closed joelweinberger closed 7 years ago

joelweinberger commented 8 years ago

At the very least, suborigin names should not be allowed to be a pure number, as in the serialization this could easily lead to parsing bugs that confuse the suborigin name with an IP literal. It's probably sufficient to just ban starting with a number, although perhaps we should outright disallow numerals.

annevk commented 8 years ago

Maybe we should instead figure out what is absolutely safe in all the various contexts and use that? E.g., lowercase a-z?

devd commented 8 years ago

I like the lowercase a-z idea. It also gives us ability to namespace later via upper case / numbers (for #40 )

ghost commented 8 years ago

a-z would break our current usage of suborigin in IPFS, where we use multihashes as suborigin names to isolate e.g. /ipfs/Qmfoo from /ipfs/Qmbar. I suppose we could encode the hashes with a-z only, but that's less ideal than base32.

It's probably sufficient to just ban starting with a number, although perhaps we should outright disallow numerals.

Both of these would work for go-ipfs :+1:

devd commented 7 years ago

closed per above merge