On Nov 30, 2007 11:33 AM, Steve Marquess <[EMAIL PROTECTED]> wrote: > Brad House wrote: > >> Brad, sorry, I didn't mean to come across as negative. The point I was > >> trying to make is that once a validation starts I can't afford to delay > >> it to deal with problems that are discovered in the already frozen > >> baseline, unless those problems are critical to the requirements of the > >> paying sponsors. Hence we don't solicit general public input for > >> in-process validations. ... > > Yes, that is understandable. Any code going through validation at that > > time cannot be touched. I think what Kyle asked for was prior to the > > next validation starting, a 2-week window where people could provide > > patches. Basically a 'last-call', or at least some projected timelines > > for when it would be submitted so we know if the code is 'close-to-final' > > before we try to provide patches (at least portability patches as is > > my selfish concern).
...basically, yes. I don't particularly want in-validation input capability, since (as Steve M points out) it's pointless. However, I am honestly annoyed that there have been two validation cycles past without (still!) a working FIPS-validated module for the Intel Mac. I know that at least HPUX64 had the same issue (I know I've got the tag wrong, but you know to which I refer). This... well, honestly violates my sensibilities. I just want to have the opportunity to know that what is submitted will actually run on the platform I must use. > Well, a single two-week window is reasonable. In thinking through the > issue more I realize there is another reason I've not been anxious to > solicit patches form the whole world. The deadlines in the validation > process are asymmetrical in that we as the vendor have to keep to tight > schedules to have any hope of obtaining a validation in time to be > useful to the sponsors, while the timelines for test lab or CMVP > response to our inputs are always open ended. That means that I can > state a deadline, have contributers frantically scrambling to code or > test in the short time allotted, only to find that nothing happens for > days or weeks afterwards and as a consequence a mod from someone else > may subsequently be slipped in with no fuss or bother. The poor guy > that worked all night or through the weekend to meet the original > deadline I announced isn't happy when that happens. Huh. You've just basically admitted that you have given up having any kind of hope of having any kind of input into the process. I should point out that you do have a fairly important role: you are the only gateway through which users have any input at all. At what point does the submission become 'fixed'? Is it 'at the moment you submit it'? Or is it 'at the moment they acknowledge receipt of it'? If it's the latter, then you still have some input: you can make it policy that you won't make any changes outside the sponsor's needs after the initial submission. This would give cause to enforce the deadline that you stated, as far as community input. > So a "last call" timeline is going to have to be with the understanding > that I can't really predict when the final cut-off point occurs. As I've just mentioned, you can -- at least as far as community submissions goes. (baseline, add sponsor requirements => prefips, add community submissions => submission, add sponsor requirements/changes => final submission) Quite honestly, if the CMVP needs to adapt to open-source methods, open-source also needs to adapt to CMVP methods. The problem is not so much that there are huge WTFs, the problem is that it's an open-source project that isn't truly "open" -- nobody can add anything, there's no communication as to what code is being prepared for submission, there's no communication as to when code is being prepared for submission. As well, no communication is happening as to what the procedure is even evolving into. So, if anyone else wants to take any open-source cryptographic code through the validation process they still have to go all the way from square 1. Don't get me wrong -- I understand the reasons you've put forth for why things have been done the way they were, and I'm not trying to say that it would have been feasible or useful to try to deal with all of the ramifications of being user-open. (Quite the contrary -- I'm told that FIPS validation isn't "pleasant" for anyone, closed- or open-source model aside -- and if you'd tried to deal with the CMVP stuff while still getting user input, you wouldn't have been able to keep to your schedules. Now, though, you have more knowledge of the process, and more knowledge of when and where input can be solicited; it would be very nice if you let those who can't afford CMVP validation but still have an interest in a well-rounded and functional FIPS-validated cryptographic module for their platform be able to contribute.) However, I'm going to go out on a limb and suggest that "not soliciting input from the users" weakens the OpenSSL development process, and not only as it applies to FIPS. When's the last time a post was made to the -devel list with a description of a checkin to the source tree by someone with commit access? The users aren't included in the process, the information isn't disseminated -- there's no information the users have to give any guidance as to what is being worked on or focused on or even why, so there's little information made available as to what needs testing, what needs clarification, and what to comment on. (As a side note: Mac OS X/Intel doesn't have a FIPS-validated module available from either Apple or any third-party that I've been able to see. Mac OS X/PPC has OpenSSL, but no validated module from Apple. Apple's been having its own delays on validation. Since I need FIPS for my project, there's nothing that I can do here -- I can develop huge swaths of code that wait years to see fruition, or I can do nothing.) > I also think checking the head of that branch is worthwhile, because any > new validation will start from that point. While new problems may be > introduced with new development it's unlikely that any problems already > there will spontaneously disappear. So HEAD is where the active development happens, and tags (not branches) are created to mark the milestones? Alright. (It's good to know how the development process works, so that we can understand how best to fit in with the development.) > -Steve M. I am very sorry if my tone is inappropriate; I'm very glad that you're at least recognizing that there are issues in the way that it's been handled up to now, and seem to be open to suggestions on how to fix the process. OpenSSL is 'mature', and so its changes are more iterative than revolutionary -- all I want is the ability to contribute to the final result of the FIPS validation process, even if the only contribution I can make is to verify that yes, it compiles and tests and runs properly on my platform. Thank you again, very much, for your time and effort in shepherding this clowder of cats through a process designed for sheep. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
