Jedy: You mention that this new program we are removing interacts with keys. How does this affect export control license forms, if at all?
Whenever we make modifications to our builds that affects the way encryption is handled/managed, we should highlight the details and discuss on this list. Any change to modules like GnuTLS, gnome-keyring, and any other desktop modules that we know have encryption logic should be carefully looked at and we should have a clear understanding of the encryption impact. Could you describe? in more detail what affect (if any) this change makes to encryption. In the desktop stack, the three modules with identified encryption logic are: gnome-keyring, GnuTLS, and D-Bus. That's all I am aware of. Is anybody else aware of any other uses of encryption in the JDS stack? Note that areas where encryption is managed by the server (evolution IMAP/POP passwords, etc.) do not need to be mentioned. Nor does NSS/NSPR used by mozilla/firefox, or PAM used by GDM/xscreensaver since these (like PKCS) are managed by the Solaris ON team and not by the desktop team. However any plugins into these frameworks (such as PAM plugins, SASL modules, etc.) that are delivered by the JDS stack should be mentioned (I don't believe there are any, but just trying to be clear). Note that in our JDS builds we rip out the gnome-keyring encryption logic and replace it with calls to PKCS. Therefore we don't have export license control issues with gnome-keyring directly and instead depend on license control for the PKCS library. That said, we still need to review changes to gnome-keyring to ensure there isn't any new encryption logic that likewise needs to be modified to use PKCS. GnuTLS does contain encryption code and needs to be the most carefully looked at module in this regards. If things change (like, say, support of higher bit encryption rates or new/changed/extended encryption protocols) then we should be aware. D-Bus uses SHA-1 hashing, which isn't strictly encryption. D-Bus also supports SASL, so users can plug-in their own authentication mechanisms to be used for D-Bus connection authentication. D-Bus does not include any SASL modules. We probably should modify D-Bus to use the similar function in libmd.so (provided by ON) to avoid multiple implementation of SHA-1 on the system. Anybody want to help with this? ORBit2 also supports authentication mechanisms that are similar to xauth. I don't believe there is any encryption logic here, but probably good to keep an eye on code, in general, that does any sort of authentication handshaking like this. Should we make the above sort of statement a bit more clear in our JDS code review process? That security/encryption changes should be reviewed a bit more closely. In fact, I'd also suggest that bumping the version # modules known to contain encryption logic (GnuTLS, gnome-keyring, D-Bus) should also be given a bit more careful review than we do for other modules. Brian >> I think you need to be more detailed about what that tool does, and why there >> are no current dependencies on it. Saying that 'Evolution doesn't need it' is >> insufficient. > > > psktool Simple PSK password tool > Very simple program that generates random keys for use with > TLS-PSK. The keys are stored in hexadecimal format in a file. > > Because it's not included in the old version of gnutls which we shipped > before so no one uses it right now. > > Regards, > > Jedy Wang >> >> Glynn >
