fix typo and regular expression of algorithim

[x1022as]

regular expression of algorithim in defs-image.json:
"pattern": "^[a-z0-9]+:[a-fA-F0-9]+$"
make descriptor.md consistent with it.

Signed-off-by: Deng Guangxing dengguangxing@huawei.com

[wking]

40d169b looks good to me.

[philips]

LGTM

[stevvooe]

defs-image.json is not the specification.

This was provide to allow case-insensitivity (although, we don't clarify this). If we do this, we would also have to remove [A-F] from the hex portion. In general, we should maintain that lower(digest) == upper(digest).

[wking]

On Wed, Aug 31, 2016 at 01:35:01PM -0700, Stephen Day wrote:

This was provide to allow case-insensitivity (although, we don't
clarify this).

Case-insensitivity isn't hard to support, but I don't see a reason
to support it. Can't we just require lowercase hex?

[wking]

On Wed, Aug 31, 2016 at 01:44:38PM -0700, W. Trevor King wrote:

Wed, Aug 31, 2016 at 01:35:01PM -0700, Stephen Day:

This was provide to allow case-insensitivity (although, we don't
clarify this).

Case-insensitivity isn't hard to support, but I don't see a reason
to support it. Can't we just require lowercase hex?

Actually, I'm pretty sure we don't want to support case insensitivity,
because allowing it increases the chances of two otherwise-identical
descriptor (or descriptor-containing) blobs having different hashes.
You could make the APIs case-insensitive if you really want to, but by
the time stuff makes it down to image-layout or the wire, digests
should be all lowercase. I'd rather just require that at the API too
(with engines backed by directories on case-insensitive filesystems
taking care to downcase filenames as they read them off the disk).

It would be nice to have case-sensitive ref names too, but I don't see
an easy way to do that in storage backed by a case-insensitive
filesystem without #174.

[vbatts]

LGTM
please rebase

[x1022as]

rebased, waiting for the CI ;)

[jonboulle]

LGTM

[stevvooe]

Sorry guys, not LGTM

The <algorithm> portion of digest needs to support tarsum.v1+sha256 definitions to at least reject them with a proper error message. We also need to be able to handle digest variations, such as sha3-256, blake2b-512 or git+sha1.

Digests in this class are valid syntactically but may not be supported.

This PR should only remove the uppercase components. We should also add a statement that a digest MUST be case flattened before parsing and verifying.

[stevvooe]

Sorry I missed the above in the initial review.

[wking]

On Thu, Sep 08, 2016 at 12:40:17PM -0700, Stephen Day wrote:

The <algorithm> portion of digest needs to support
tarsum.v1+sha256 definitions to at least reject them with a proper
error message. We also need to be able to handle digest variations,
such as sha3-256, blake2b-512 or git+sha1.

With af00de0, this PR updates descriptor.md to match defs-image.json.
We want that consistency either way, but it sounds like you're asking
for [a-f0-9_+.-]+. While we're adjusting the set of allowed
characters, are there any others that should be included?

[stevvooe]

With af00de0, this PR updates descriptor.md to match defs-image.json.

Yes, but as I said before, defs-image.json is not the specification.

I'm asking that [a-z0-9_+.-]+ (note that we cover to z here) be accepted here. This character set is similar to what is allowed by semver, so I don't see a need for expanding this further.

This provides for sufficient future proofing to defer algorithm to supportability validations rather than syntax validation. This will make for a much smoother transition if we ever encounter the dreaded break of sha256.

[wking]

On Thu, Sep 08, 2016 at 01:05:07PM -0700, Stephen Day wrote:

With af00de0, this PR updates descriptor.md to match defs-image.json.

Yes, but as I said before, defs-image.json is not the specification.

Agreed, but i think everyone also agrees that the specificaiton in
descriptor.md should be changed. I'm trying to figure out if we have
a consensus on what it should be changed to ;).

I'm asking that [a-z0-9_+.-]+ (note that we cover to z here) be
accepted here.

Sounds good. And I'd missed the ‘z’ earlier, so thanks for pointing
it out :).

[x1022as]

On Thu, Sep 08, 2016 at 12:40:17PM -0700, Stephen Day wrote:
The <algorithm> portion of digest needs to support
tarsum.v1+sha256 definitions to at least reject them with a proper
error message. We also need to be able to handle digest variations,
such as sha3-256, blake2b-512 or git+sha1.

this makes [a-z0-9_+.-]+ reasonable, and thus we need to change the def-images.json as well. I think we should make them match anyway. what do others think about it?

[jonboulle]

LGTM

[wking]

75a51ed looks good to me.

[stevvooe]

LGTM