The 'rt' is the 'request tracker' system. It essentially opens a trouble ticket, which allows for any action on the patch to be identified and tracked. (When it's updated by the core OS developers when they take an action on a patch, anyway. :))
It also -- more importantly to you, in this case -- automatically sends a mail to openssl-dev when a new request is submitted -- which allows for the discussion that you're looking for to take place. -Kyle H On Mon, Mar 9, 2009 at 4:52 PM, Allan K Pratt <[email protected]> wrote: > Kyle Hamilton <[email protected]> wrote: >> The best way is to send a patch (unified diff) to [email protected]. ... > The module owner will review the patch and apply it if appropriate... > > Thanks for the guidance. I'll try that route. > > I guess I was hoping to get a little bit of back-and-forth with the > component owner(s), to validate the *idea* of the patch first. I don't > know the process on the "rt" list: does sending a patch there start a > discussion, or is it more of a yes/no decision at that point? Since this > patch isn't about correctness on its face, and understanding its > motivation and import might take some discussion, I'd like to connect with > a person rather than send the patch to a potential black hole. Will I hear > from somebody if my patch is rejected? > > By the way, a Purify user on this list asked privately about the symptom, > the behavior when PurifyPlus goes bad. The program instruments without > error, but then it misbehaves at runtime if you execute the functions in > des_enc.m4. Those functions have names like DES_encrypt1 (and -2 and -3) > and DES_decrypt3 plus a couple of others starting with DES. If you don't > end up in those you'll be fine. The user who reported this got a SEGV, > which at least has the virtue of being obvious. I'm not sure, but it is > also possible that you could silently get incorrect encryption or > decryption without crashing; this would be much worse from the user's > perspective. It depends on how those tables are used. (I didn't grok the > whole implementation, just identified the trick that gave Purify grief.) > > -- Allan Pratt, [email protected] > Rational software division of IBM > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
