[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] On resetting passwords

From: Bob Proulx
Subject: Re: [Savannah-hackers-public] On resetting passwords
Date: Mon, 13 Feb 2017 18:03:10 -0700
User-agent: NeoMutt/20170113 (1.7.2)

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.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]