[pkg-discuss] Re: Updated sha-2 webrev
- From: Tim Foster <
- Cc: Danek Duvall <
- Subject: [pkg-discuss] Re: Updated sha-2 webrev
- Date: Wed, 02 Oct 2013 12:26:25 +1300
On 10/ 2/13 12:03 PM, Danek Duvall wrote:
Tim Foster wrote:
* tests that non-debug pkg(1) (ie. SHA-1 and SHA-2 aware) can install
future packages that may only contain SHA-2 hashes
What happens with the client as you have it if it sees a package that only
contains "sha512" hashes? Do we do something sane, or do we keel over?
Does that require any catalog code to support?
We keel over gracefully: Here's a repository that contains only SHA-2
hashes, and a client that only understands SHA-1 hashes trying to
install a package from it:
$ cat repo/publisher/test/pkg/mypkg/1.0%2C1.0%3A20131001T231018Z | pkgfmt
set name=pkg.fmri value=pkg://email@example.com,1.0:20131001T231018Z
file path=etc/motd owner=root group=sys mode=0644 \
$ pkg -R image install mypkg
Packages to update: 1
DOWNLOAD PKGS FILES XFER (MB)
mypkg 0/1 0/1 0.0/0.0
Errors were encountered while attempting to retrieve package or file
the requested operation.
file protocol error: code: 2 reason: No file could be found for the
specified hash name: 'NOHASH'.
Repository URL: 'file:///home/timf/projects/ips/sha256-pkg.hg/repo'.
(happened 4 times)
* "pkg.elf.sha256" is now the attribute name for SHA-2 elfhashes
So Tim and I had a quick discussion on IRC, wherein:
- I said I didn't like "pkg.<type>.<hashname>" because of potential (if
unlikely) conflicts between <type> and some other real word we'd want
to use in that position, hence I would want to give the file type its
own namespace: pkg.filetype=<type>;
I'm fine with this, and would like to suggest 'elf' as the first
pkg.filetype value. Values ought to be lower-case.
- I suggested pkg.content-hash.<hashname>;
- We agreed that having the filetype in the action metadata was very
useful, and possibly necessary;
Yes, I'd really like to be able to still find all ELF files delivered by
- I stated that having "elfbits" and "elfarch" were basically useless,
"because it's there" attributes, could be dropped, and would make up
for extending the length of "elfhash" to "pkg.content-hash.sha256";
I'm fine with dropping these attributes now - given that we have
pkg.variant.arch, having elfarch is mostly redundant (we tend not to
have diskless systems where installing x86 packages on sparc systems is
necessary anymore) and I don't know if anyone's ever used elfbits for
anything useful. Over time, I could see 32-bit files going away..
I'll file an RFE unless there are objections.
- Tim, through his tears of frustration, agreed to do the work.
Tim, is that about right?
Yep, that's it exactly - I'll have an incremental webrev out hopefully
by the end of today once I've reapplied my running mascara :-)