Hello Ineiev, Ineiev wrote: > I've just thought that we could use registered GPG keys > to send the links encrypted. > > What do people think?
That is an interesting idea. I like it! I think it would be a nice feature to offer. But I would not make the the default. At least not initially. People have such trouble right now reading email that I think if we made that the default that most people would not be able to handle it. Call me pessimistic if you like but it comes from a long time dealing with the public. But I think offering it as an option on the account/lostpw.php page would be a good thing. As an optional feature it would also allow us to gain experience with how well people are able to use the feature without affecting the majority of users too. But I am at a loss as to know when it should be enabled? Because if we made it an optional submission then since anyone can trigger the lost password recovery action we can assume that it would be activated for everyone without being encrypted. Therefore I think it would need to be a persistent user preference option saved in the database. One could set it as a preference for their account. Perhaps we would even encourage it when a user uploads their GPG key. WDYT? As to implementation I would prefer if this were implemented in two parts with a second part being an external standalone helper. This is just my preference and philosophy and others might disagree but approaching Savannah's web code from the outside it is best for me if I can operate components in isolation. So that it can be tested standalone. This touches upon several different components and when things change, such as GnuPG version, then how will we unit test the feature? Therefore my preference would be to have the encrypted email feature be implemented with a standalone helper that could operate independently of the web server. Your prototype already makes use of external processes so this would be no different. It would just locate more of the work in a helper script. But then the helper script would be run standalone for unit testing and verifying the interface to gpg and the system. Continuing on why I think this way as I inspect the code I become worried about a few things that are difficult to do within PHP directly but are much easier to do in other language. For example: > +$temp_dir = shell_exec('echo -n `mktemp --tmpdir -d lostpw.XXXXXXXX`'); > +if($temp_dir != "") > ... > + shell_exec('rm -fr '.$temp_dir); There are a couple of issues with the above. One is that while shell_exec will check for the return code of the echo the passage there means the exit code of the mktemp is lost. I have this fear of what happens if some snafu occurs and the external call to 'echo -n `mktemp --tmpdir -d lostpw.XXXXXXXX`' were to return a partial string. Sure we expect it will return /tmp/lostpw.XXXXXX but lets ask what happens if the output is truncated "for whatever reason" and it only gets "/" emitted? Then we are relying upon GNU 'rm's recently added safety net preventing removing / but I try never to rely upon that since it might be run on a BSD system without it. Sorry, but there is also one last thing too. One should never use echo with an option such as -n or -e as such usage is inherently non-portable. Instead use 'printf' as that is POSIX standard and portable everywhere. But all of those problems can be avoided by using an external standalone helper. Additionally such a helper could be used in other parts of the site that send email too. My preference even today would be a shell script for something simple like this. Or if it is complicated enough then Perl since most of the other helpers in Savannah are also in Perl. But I realize these choices depend upon the taste of the person reading, writing, maintaining them. Bob
signature.asc
Description: PGP signature