If the user doesn't pass any flag, stage1 images will be taken from the default stage1 directory or from the directory where the rkt binary is. In that case, we don't check any signatures.

No, when user doesn't pass any flag, stage1 image paths will be taken from configuration. If there's none, it will be taken from build defaults.

No, when user doesn't pass any flag, stage1 image paths will be taken from configuration. If there's none, it will be taken from build defaults.

OK, I guess I meant if the user doesn't pass any flags and there's no configuration :P

Ok, first when no --stage1-* flag is passed - when looking for stage1 image we have three things available - name, version and location. Name and version together make the image reference (like coreos.com/rkt/stage1-coreos:1.2.1). The location can be either a URL or an absolute path. All of those can be overridden by a configuration.

The image reference is used to look for the image in the store only (there is no fetching from remote), so at this point signature checking is not relevant. If there is no such image in the store, we use the location to fetch it and that's where we have to decide if the signature should be checked. In this case we should skip the verification if the location is either the same as the build-time default location (buildDefaultStage1ImageLoc) or location is somewhere below the build-time default stage1 images directory (buildDefaultStage1ImagesDir).

Now, when --stage1-* flag is passed, then each have to be considered case by case.

• --stage1-path and --stage1-url - this is simple - skip the verification if the flag value is the same as the build-time default (buildDefaultStage1ImageLoc) or the path is below is somewhere below the build-time default stage1 images directory (buildDefaultStage1ImagesDir).
• --stage1-hash - verification is not relevant.
• --stage1-from-dir - skip the verification if the stage1-images dir is the same as build-time default stage1 images directory (buildDefaultStage1ImagesDir) or even a subdirectory of it.
• --stage1-name - I have no idea about this. I'd say, just do the verification. The verification will be skipped if we already have the image in the store, so we are fine. The problem may arise when the discovery returns the same location as the build-time default location (buildDefaultStage1ImageLoc), because we cannot tell the fetcher to skip the verification, because the location is already known to be verified.

Implementation-wise, since the are some various conditions when the verification should be skipped or not, it would be better if the getStage1Finder function would take a boolean parameter telling whether the returned Finder should have its Ks field filled with a keystore or not.

Thanks for the write-up. That still misses the case where we use the image in the same directory as rkt.

One nit, otherwise LFAD.

I guess I need to update the documentation

LFAD if green.

I hope it won't break too many workflows, but it looks like it is a right thing to do.