Hi Michael, > So I would ask you to make an exact description what we want to do and > wait until october. I know that time is usually the thing which nobody > has but the problem is that if we make the decision that we no longer > support DBM then we can really easily integrate this stuff in OpenCA::DBI.
yes, I completely agree that it is not desirable to add this stuff into the now stabilizing code. > Another solution of this timing problem is that we wait until next week > (Max is back at 2004-Aug-28) and then start a discussion over the DBM > support. I think I will create the branch openca_0_9_2 at monday. So > after this timestamp we can start breaking the CVS :) I don't think we should branch the project right now. It is a desirable feature, but I think it can wait. Our project will go production around October 15th, and I need a stable state till then :-) (BTW: I will be on holiday from Sep 3rd till Sep 17th.) > A clean database design is always the best way. So never mix fields and > use two rows for objecttype and key (be warned keys can have non > numerical serials). We need some sequence generators too. This was > implemented some time ago and must be re-introduced for this stuff. Again, I agree completely. Database related stuff that came to my mind: - sequences if supported by DB (There seems to be some interesting code when it comes to detecting the "highest" serial number. :-) - and the serial search on CRLs could be improved as well...) - global transaction handler: currently transactions seem to be supported on a DB request layer, but I think that file system operations are not committed/rolled back according to the global outcome of an operation. example: are OpenSSL changes (private key generation, serial number etc) properly rolled back on error, or does it result in an inconsistant state after a DB rollback? I may be wrong, but I think this is still a weak point. >> * Introduce a new table (e. g. 'audittrail'): >> objectid: varchar (OR objecttype: varchar; objectkey: varchar), see >> above >> userid: varchar >> (role: varchar - ) >> action: varchar >> timestamp: date > > 1. objecttype: varchar; objectkey: varchar > 2. role must be present because this is the only chance to detect > failures in an external authentication program if it returns a wrong role. yup. >> * On each insert/update in the database add a row to the 'audittrail' >> table. The entry should state timestamp, logged in user ID for >> the session (if available, it might also be DN of a signature's >> creator) and action. >> It might be possible to extend the DBI/DB interface to add this >> entry automatically (problem: pass userid/session information and >> action to the DBI methods; sometimes the DBI class may be able >> to deduce the 'action' information from the information passed) > > ... and this is the problem. I noticed... > The problem with this SQL like stuff is that we have problems to > implement it with DBM. Therefore we should start next week a discussion > about DBM. Nevertheless DBM will be supported in 0.9.2. Yes, and so we should postpone this until 0.9.3 development. There are some other interesting features that are much easier to implement that could make it to the next stable version. I think I will have some useful other additions till I leave for holiday. But it was good to discuss this, now I understand the impact of the necessary changes more clearly. Martin ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
