|
Comments
|
This is going to involve changing files and changing the Gatekeeper process.
jmcp has already agreed to set CODESIGN_USER now for the tonic builds, which
will make it so the full-proto area is correctly signed.
This will allow me to modify bindrop to pull crypto binaries from the proto
area, as opposed to the previous night's packages (which may not be in
sync with the current contents of closed).
signproto currently already generates a file that contains a list of all
executables it is going to sign, in the following format:
Crypto_v2 kernel/drv/amd64/dprov
Crypto_v2 kernel/drv/amd64/dca
[...]
So, I can take that file as input to bindrop so we do not have to duplicate
that effort of finding them, and just sed out the dprov entries and the leading
credentials and whitespace.
Thanks to Rich Lowe, for pointing out to me that my current design will break internal
developers trying to build close source/signed file tar balls.
Deleted a bit of my last note, as I've realized this is actually more
complicated than I thought. I have the following givens:
1) We don't want to rely on pulling crypto modules out of SVR4 packages because:
* they are going away
* the data may not be in sync with the rest of the tonic build we've
* just
done, which may lead to corruption, panics or other odd behaviour.
* The current list is hardcoded and error prone
2) The entire reason we in include crypto modules in the on-closed-bins*tar
bundles
is because they need to be correctly signed and regular developers (internal
and external) cannot do this. Because we do provide certificates for
internal
developrs to sign with, this is only an issue for internal developers that
want to share their closed source binaries with external folks.
3) Any developer actually making changes to crypto files cannot use bindrop
anyways, because it always pulls the crypto modules from the ON GK's package
archive. This problem does not need to be solved for this work.
4) One idea was to pull the crypto modules from the proto area if CODESIGN_USER
was set, but then pull them from the ON GK builds if it isn't. That doesn't
work, because GKs don't save proto areas - just bfu archives (going away)
and SVR4 packaging archives (also going away, see #1)
So, I've come to the conclusion that we actually need to deliver a second *tar
archive out of bindrop: one that only contains crypto modules. This will help
alleviate the name confusion (since these sources are not closed), and make the
GK's the single source for delivering these objects for external use (which they
were anyways, but we were having individual developers repackage the GK bits).
This requires:
I) ON GKs sign all tonic builds (jmcp already agreed to this)
II) ON GKs upload the additional tar files (debug/non-debug/sparc/x86)
II) Any documented process on providing archives externally for testing
will need to be augmented to tell people to download the crypto binary
tar ball most closely associated with the build level of these bits.
(does anyone know of any such documentation?)
III) Checking if CODESIGN_USER is set in the environment and creating the crypto
binary archive only if that is the case.
IV) Eliminating "CRYPTO_BINS_PATH" as an alternate mechanism for saying where
to get crypto from if you're running bindrop as a developer.
-or-
have GKs make sure all cryptp bins (and closed bins, for that matter)
are in a "well-known" location so this will still work.
Valerie's previous comment includes a very important point: "The entire reason we include crypto modules in the on-closed-bins*tar bundles is because they need to be correctly signed and regular developers (internal and external) cannot do this."
I'd argue that it's time to stop making a distinction between internal and external developers in this area. Once the crypto binaries are in their own tarball, we could have internal developers use that to obtain signed binaries (exactly like external developers do) instead of using an internal-only certificate and key.
In addition to removing confusion about the handling of the internal certificate and key, this would improve the experience of building externally by making the process more similar to the internal process.
One consumer I was not aware of before of bindrop's tar ball: bfudrop.
This seriously complicates the design as there is not currently a path
I could point bfudrop to find crypto tar balls for a specific build,
if this wasn't being run by a gatekeeper.
There will be a lot of change in this area coming up, and this might be able
to be addressed as part of that work, but the risk is suddenly higher than
the reward at this time.
Other consumers/test cases to consider (thanks, Liane):
Nightly for external developers (ie start with only open source and try to build
with closed bins & the crypto bins).
Documentation that will need to be updated, courtesy of kupfer:
http://tonic.eng/xwiki/bin/view/Main/Posting+Detail.
http://tonic.eng/xwiki/bin/view/Main/Publishing might also need
updating, and it might also point to pages that need updating.
You'll also need to update the documentation for external users that
tells them how to do builds. Besides the ON Developers Reference, these
pages (at least) will need review:
- http://www.opensolaris.org/os/community/on/install_quickstart/
- usr/src/tools/opensolaris/README.opensolaris.tmpl
Currently, most of the signed crypto code is tagged with
$(CLOSED_BUILD), which means it doesn't get built for an open-only
build. Considering that we plan to eventually stop using internal
signing certificates, we could extend this practice so that the crypto
code is not built unless it will actually be signed and used. But
that will make it harder to detect build problems in the crypto code
that are triggered by changes elsewhere in the source. Also, it means
that developers have to remember to tag signed crypto modules with
$(CLOSED_BUILD), and we already have one case where this hasn't been
done correctly (rsa).
So we should go in the other direction, and build open-source crypto
all the time, even if it won't be used.
Such a change requires additional work so that (cap-eye) Install
generates kernels with usable crypto. Keeping in mind that Install
copies out of the source tree, not the proto area, the simplest
approach is for Install to be responsible for copying in the proper
crypto modules.
This smells faintly of mission creep, so it's tempting to continue
tagging crypto code with $(CLOSED_BUILD). Don't remove the tags until
we stop using the internal signing certificate.
But it turns out that we want to update Install anyway. So there's no
benefit to keeping the crypto code tagged with $(CLOSED_BUILD).
The reason we want to update Install is that on SPARC platforms, there
are crypto modules in /platform. If we do nothing to Install, these
modules will be inaccessible when the developer boots a glom (Install
-G) kernel.
The Install script works by getting a list of kernel modules,
including source and installation paths for each module. The list
gets run through various internal filters before it is finally used.
We'll just add another set of filters that will change the source
entries for crypto modules to point at the signed crypto instead of
the build tree.
External developers currently unpack the closed bins tarball before
starting a build. For the sake of consistency, I thought about having
the crypto tarball work the same way. There are two problems with
that approach: first, it's more manual labor for external developers.
Second, project gates will be using "nightly -O", and it seems cleaner
to just pass through the crypto tarball that they were given, rather
than repacking a directory tree.
So the environment variable that points to the signed (input) crypto
will refer to the tarball.
In the future I'd like to have similar support for the closed bins
(point to the tarball, rather than a directory). But I'd like to defer
that set of changes for now, especially since I would not want to
break the existing practice of referring to a directory tree.
As with the closed bins, there will be 2 crypto tarballs: one for
debug binaries and one for non-debug binaries. (The pointer should be
to the debug tarball. The tools will adjust for non-debug builds.)
The non-debug tarballs will unpack into proto/root_$MACH-nd. This
complicates the automatic unpacking if MULTI_PROTO=no, but it makes
the contents a little more self-identifying. And it means we could
have a single crypto tarball with both debug and non-debug binaries if
we think that's the right approach. (The crypto tarballs are around
1.5MB, which is significantly smaller than the closed-bins tarballs.)
I'm afraid I lied slightly in public comment #7 about whether there is
a benefit to keeping the crypto code tagged with $(CLOSED_BUILD). If
we didn't build the signed crypto for an open-only build, we could
have a transition period where the tools work with old workspaces
(crypto and closed bins in the same tarball) or new workspaces
(separate crypto and closed bins tarballs).
With the planned approach, external developers will need to upgrade
their source, closed bins, tools, and crypto all at the same time.
After discussing this with the ON gatekeeper, we decided to generate
the crypto tarball for all signing builds. To simplify gate
automation, the tarball will go into the packages tree, with a
datestamp and a stamp-free symlink, e.g.,
on-crypto-20091125.i386.tar.bz2
on-crypto.i386.tar.bz2 -> on-crypto-20091125.i386.tar.bz2
"nightly -O" will also generate a crypto tarball. If it's a signing
build, the crypto will come from the built sources. Otherwise,
nightly(1) will require that a crypto tarball be provided as input,
and that tarball will be passed through.
So that the crypto tarball is always in the same place, "nightly -O"
will put the tarball in the same place as a normal signing build.
This is different from the other deliverables from "nightly -O", which
go in $CODEMGR_WS, but this discrepancy should be easy for consumers
to script around if they need to.
For the ksh scripts that I've created or modified, I've modified functions to be declared with "function foo", rather than "foo()". This is so that variables in the functions are lexically scoped with ksh93. (With ksh88, both forms have lexically scoped variables.) This is crucial for nightly, which is too big to be maintainable with a global namespace for variables. It's not as important for the other scripts, but it's generally cleaner.
ksh93 has at least one other difference between "function foo" and "foo()", which has to do with trap handling in a function. Install(1) and nightly(1) both use "trap" for cleanup after a signal; they are compatible with the ksh93 semantics.
|
