Comments inline... On Sun, 2002-04-14 at 00:51, John Ridge Cook wrote:
> This is quite correct. I pointed out that for commercial applications GNuPG > was available, though I mangled the addresses. My main gripe against GPG is > that its attitude of pushing the edges while not worrying about > compatibility. Also while being in development for about 3 years, none of What compatibility issues is GnuPG not addressing? The only issue I've ever had was solved by picking up non-official modules for restricted algorithms (though now RSA is included). Though, I do note on their FAQ they list a few problems, a brief explanation of them, and how to handle them. > the authors feel its necessary for a consistent, official, average user > friendly GUI. There are several front ends available, but their reliability > in various operating environments differ, as do the openness of their source > code. > > While many have grown up or have learned comandline, the vast majority of > users came after DOS. What is the reason for reverting back to 1992 and > looking for a front end that will work on your machine? Many other programs > have had much less lead time and provide perfectly good GUIs for Windows and > Linux. Is it a techno attitude saying "If you don't know commandline, you > should not use strong crypto." ?. I don't know, but it seems purposely > designed to be intimidating or inaccessible to the average user. If Note: my comments are based on personal beliefs and observations - I have no idea how GnuPG developers feel on these issues. I suppose one could say that there is some elitism involved in the question of a GUI interface for GnuPG. But its hardly an attempt to keep strong crypto from average users. Instead, it is a simple matter of demand. GnuPG first appeared on Linux with various Unix flavors quick to follow. Windows showed up as an included platform far later. This is a good indication that GnuPG's main developers are Unix developers (if there were more Windows developers working on the project, Windows compatability would have appeared right from the start). Within a Unix environment (and user base), a GUI is not as strong a requirement. Even PGP for Unix is command-line only. This leads in to how Open Source works. Open Source has been referred to as "scratching an itch". Developers code based on their own desire to satisfy a requirement (usually a tool they would like, or a bug that bothers them - though it could be for pay). If a developer does not feel a demand for a feature, that feature will not appear (assuming there aren't also technical or legal reasons). It should be of no suprise that a GUI environment has not been a high priority of the GnuPG developers who satisfy vastly Unix-centric requirements. That is not to say there is no demand. Most of the Open Source email clients available have built-in support for GnuPG. And there have been a few projects to create a GUI frontend to GnuPG using various GUI toolkits (most of them somewhat cross-platform). Surely, NAI's actions have only increased the demand/itch for Windows integration / GUI environments for GnuPG. The GnuPG folks are at least aware of this demand and have created a library called GPGME. The stated aim of this library is to allow easy and secure interaction with GnuPG (and perhapse other applications later). This should aid in creating GUI frontends and email client integration. In fact, WinPT uses GPGME. Of course - this strategy presents bennifits and risks. The risk is in the security of the code. GnuPG itself will undergo greater scrutiny because of its popularity as well as its user base. A Windows GUI front-end is less likely to get the same review and thus there is an increased likelyhood it will become the source of key compromise. Although, as these things become more popular, it is also possible they will see more stringent review (assuming the code is available to be reviewed). The bennifits reflect both Open Source and Unix concepts. Open Source tends to favor creating building blocks that allow others to then build on existing work. And Unix users and developers often favor using multiple powerfull tools that interconnect to perform larger functions. First, GnuPG is making it easy for others to leverage their work to improve their own projects (email clients and GUI front-ends being our two examples in this discussion). The GnuPG developers will not have to be the central focus for all applications using GnuPG. Thus, there will be more choices (or at least the potential - scratching itches and all that) for the end user. Users will then be free to use whichever tools best suit their needs. And if the tools are created properly, they will be interchangable... allowing users, for example, to change GUI frontends without loosing their data. This choice can be a bit daunting to someone used to a monolithic environment - IT departments can create that feel by providing a "blessed" package of tools. -- .: Paul Hosking . [EMAIL PROTECTED] .: InfoSec . 408.829.9402 .: PGP KeyID: 0x42F93AE9 .: 7B86 4F79 E496 2775 7945 FA81 8D94 196D 42F9 3AE9
