On Thu, 2006-10-26 at 12:04 -0500, Brian Cameron wrote: > 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.
Because psktool is a new command introduced in newer version of gnutls and we do not have it in JDS before ,so I think there will be no impact to encryption if we remove the command when we are building the package. Regards, Jedy Wang > > 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 > > >
