Re: [Sshpass-devel] sshpass needs a config file

[Shachar S. <sh...@sh...>]

On 26/07/13 23:16, Bruce Korb wrote:
> On 07/26/13 12:05, Shachar Shemesh wrote:
>>> So let me know if you want the patch.
>> Sending the patch to an open source project is the rule rather than
>> the exception.
>
> I only do it if it is welcome.  If it won't get applied, I won't
> bother.  :)
> As the author, you probably have an idea about whether the whole idea
> would be accepted or not.
>
> I will guess now that it would be.  Thanks!  Cheers - Bruce
I'm sorry, this simply is not how open source works. What I'm about to
say is true, to greater or lesser degree, to every single open source
project I have ever participated in.

First of all, open source project discussions are about the community.
This means you do not exclude the mailing list from your response merely
because the maintainer answered your email. Unless you have something
personal to say to me, you hit the "reply to all" button and include the
community in the discussion. It is possible that someone other than me
will have something to contribute to this discussion.

If you believe in this patch, preferably because you need it yourself,
then you write it. You send it to the list/maintainer/whatever, because,
generally speaking, having your patch available through upstream is the
best course for everyone involved (may not be as true for a "complete"
project such as ssh-pass).

This might mean that it might get accepted, or it might mean it will
not. It might even mean there is a fundamental problem with the concept.
If you want to be taken seriously, though, you show effort by writing
the patch. The rule is that talk is cheap and good ideas are a dime a
dozen. I try hard on my project's lists not to abuse anyone, especially
not those who made an effort to back their own words. This, however,
does not mean that your patch will be accepted. There are no guarantees.
If you believe in your patch (and I sure hope you do not intend to
submit a patch you do not believe in), you are free to offer it as a fork.

In some projects, you might get an answer whether your patch even has a
chance. On some of the bigger projects you will not. Either way, as a
word of advice, it is better to start your email with something along
the lines of "here is a new feature I was thinking of implementing, and
I'd love to get feedback on whether this is even needed or useful". This
way, you do not sound as if you expect someone else to implement your idea.

Specifically regarding your suggestion: I do not like it much. I have
security as my background, and I cringe whenever passwords are stored in
plain text. Your idea involves plain text passwords laying around in the
clear for much longer than the other alternatives. Then again, ssh-pass
has been a compromise from the get-go, and as you have stated, there are
tradeoffs either way. As such, if you write it, and if there is no
technical reason not to, I'll *probably* include it. After all, with the
proper warnings in the man page, a user is always free not to use this
feature.

Having said that, I think there are things we can do to make this idea
better, without compromising the usability. In fact, with a little bit
of work, we can make this into a feature that can be the recommended
method of doing things. One thing we might do is to tie the passwords in
to the ssh public key infrastructure. Most valid uses of ssh-pass are
for cases where the user only controls the client side, and the server,
for whatever reason, does not allow public key authentication. If we
offer a "remember this password" feature for ssh-pass, and particularly,
encrypt the password files with the user's private key (through the
ssh-agent or otherwise), then we might get a feature that gives you the
usability you want, while actually being MORE secure than the other
ssh-pass password passing options.

Shachar