On 02/18/16 13:59, David Woodhouse wrote: [snip ;)]
> Please trim citations. You didn't have to cite the *entire* patch just > to say that it seems right! > > You aren't one of the Outlook-afflicted. We need you to set an example > of how email is actually *supposed* to be used :) Some people think trimming is not helpful, others think it's (almost) required. I do trim emails, at the latest when they get overlong -- but when replying to a patch directly, I think I rarely do. I guess in this case it would have been justified, yes. >> I also tried to diff the "openssl-1.0.2e" and "openssl-1.0.2f" trees >> against each other, to see if "no new source changes [...] introduced >> for 1.0.2f enabling" is indeed the right thing to do. >> >> The result of that diffing is a 3000 line patch, with the following >> diffstat: >> >> 144 files changed, 815 insertions(+), 476 deletions(-) > > This is the 21st century. Nobody in their right mind deals with > software management except through git. More edifying would be to run: > > git log OpenSSL_1_0_2e..OpenSSL_1_0_2f --stat > > and/or > > gitk OpenSSL_1_0_2e..OpenSSL_1_0_2f Sure, but that requires one to clone the OpenSSL repo, recognize the tag names (yes, not too hard :)), and it's not the view that will be ultimately visible in edk2. (After embedding the exploded OpenSSL tree.) I assume this would be more manageable if the upstream openssl repo was a submodule for edk2. [snip] >> So, I hereby declare the OpenSSL updates practically un-review-able, >> even just for *scope* -- i.e., in order to see how far those changes >> extend. I also claim that the OpenSSL release strategy is not being >> implemented in reality -- the "letter releases" actually seem to be >> vulnerability-triggered *snapshots* of the 1.0.2 tree, where the code >> influx, albeit low volume, definitely meanders outside of bug and >> security fixes. > > Yeah, there's a certain amount of truth in what you say. When a high- > priority vulnerability comes up, we need a new release and people need > to upgrade. If we fix a minor functionality issue which is fairly > esoteric and *doesn't* have security implications, there *isn't* an > immediate release the same day. We'd run out of letters very quickly if > we did that! :) > > So yes, when the high-visibility issues trigger a release, a bunch of > less important fixes go along for the ride. I don't think that's a > problem. > > But trust me — as someone who has occasionally wanted to get > improvements into a stable branch of OpenSSL when they have been > considered "new features" — when I say that they aren't adding whole > piles of exciting new stuff to the 1.0.2 branch :) I can trust you alright. :) [snip] >> Now, one might ask why I care. I care because for some downstreams of >> edk2 at least, the situation that openssl has to be patched in before a >> secure boot enabled build is completely unacceptable. That makes it >> super-unwieldy to bisect a secure boot enabled build for example. It >> also requires all people who clone your tree to patch in OpenSSL >> manually. > > Actually, in practice is *isn't* so bad. Given that we don't update our > EDKII_openssl-1.0.2X.patch very often (if at all) between OpenSSL > releases, what happens is that your build tree ends up with *multiple* > CryptoPkg/Library/OpensslLib/openssl-1.0.2[def] directories. Interesting! The OPENSSL_PATH define in "CryptoPkg/Library/OpensslLib/OpensslLib.inf" would change, and the untracked files under the separate openssl-* directories would co-exist. I'm not sure about the untracked files created by Install.sh though -- they come from the different openssl source trees, but go into a common location. Maybe Install.sh should be reexecuted at each step of the bisection. > And as you > flit back and forth between EDK2 commits in your bisect, you use the > different OpenSSL directories, as appropriate. > >> Importing openssl should be a run-of-the-mill *commit* in the git >> history (and it is, for us). > > Surely this is what git submodules are for? Probably. :) [snip] >> Honestly, edk2 should either incorporate OpenSSL permanently, or build >> it 100% from an external, unmodified upstream tarball (I think this is >> what David has been working on, right?) > > As noted yesterday, we're two trivial patches from being able to use > the next OpenSSL 1.1.0 beta snapshot "out of the box" with EDK2. Do you think it will be possible to add openssl as a git submodule to the upstream edk2 repo? (I'd rather not explore that myself down-stream...) Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
