FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-07-2012, 11:40 PM
Russ Allbery
 
Default Help me DTRT with upstream naming

Hello all,

Given that this has been keeping me from packaging for Debian some
software I developed at Stanford, and I'm getting more requests for
packages, I will try to get past my mixed feelings of obstinance and guilt
and just ask for advice or help.

In 2007, to replace our legacy Kerberos keytab distribution system, I
wrote a new system that allows users of a Kerberos realm who don't have
administrative credentials to view, download, and manage selected keytabs
without having to maintain monster kadmin ACL files that only sort of
work. We then expanded its use to cover any arbitrary piece of secure
data that we wanted to manage centrally with rich ACLs, such as database
passwords, X.509 private keys, and so forth. We've been using this
heavily for the past five years, and it's pretty widely known at Stanford.
I'm starting to see other sites deploying it, and am starting to get
requests for Debian packages (which we have internally).

The problem is that the software is called wallet, both the software
itself and the primary client binary that users invoke. And, of course,
we have a bunch of documentation and automation at Stanford that assumes
that name.

I *did* do some degree of due diligence before I called it that, including
searches for other software with the same name in Debian or outside, and I
didn't find anything. I think that's still the case for the binary name;
Google Wallet, Wallet for Mac, and a few other things on mobile platforms
turn up now, but I don't think there's another UNIX/Linux binary of that
name. But, of course, it's still not a very unique name.

So, the first question is: should I rename this software to something else
before packaging it for Debian? I kind of feel like the answer is
probably yes (see the recent node discussion), but on the other hand it's
going to be a big pain for me and for users at Stanford, so I'm feeling
obstinate about it. So here's your chance to talk me into doing the right
thing. The next release would be the 1.0 release and the release that
I'd push more publicly, so if I'm going to rename it, now's the time.

The second question is: if I should rename it, what should I call it?
Does anyone have any suggestions that are more unique but that still
preserve the property of being a reasonably easy-to-remember command-line
tool for unsophisticated users? I really don't want something like
"Stanford wallet" because it's intended to be a general, extensible
solution to enterprise password and key management, and I don't want to
get into the various trademark issues and so forth that are involved in
plastering Stanford's name on it.

For those who are curious, the upstream web site is at:

http://www.eyrie.org/~eagle/software/wallet/

and the current package metadata for our internal packages is:

Package: wallet-client
Architecture: any
Depends: ${shlibsepends}, ${miscepends}
Description: Kerberos-authenticated secure data management client
The wallet is a system for managing secure data, authorization rules to
retrieve or change that data, and audit rules for documenting actions
taken on that data. Objects of various types may be stored in the
wallet or generated on request and retrieved by authorized users. The
wallet tracks ACLs, metadata, and trace information. It uses Kerberos
authentication. One of the object types it supports is Kerberos keytabs,
making it suitable as a user-accessible front-end to Kerberos kadmind
with richer ACL and metadata operations.
.
This package contains the wallet client, which talks to a remote wallet
server to store, download, and manage objects.

Package: wallet-server
Architecture: all
Depends: ${miscepends}, ${perlepends}, libdbi-perl,
libdbd-sqlite3-perl | libdbd-mysql-perl, remctl-server
Recommends: krb5-user | libheimdal-kadm5-perl, remctl-server (>= 2.14)
Suggests: libnet-remctl-perl
Description: Kerberos-authenticated secure data management server
The wallet is a system for managing secure data, authorization rules to
retrieve or change that data, and audit rules for documenting actions
taken on that data. Objects of various types may be stored in the
wallet or generated on request and retrieved by authorized users. The
wallet tracks ACLs, metadata, and trace information. It uses Kerberos
authentication. One of the object types it supports is Kerberos keytabs,
making it suitable as a user-accessible front-end to Kerberos kadmind
with richer ACL and metadata operations.
.
This package contains the wallet server, which runs under remctl,
maintains the database of object metadata and secure objects, and
responds to requests from the wallet client.

Package: keytab-backend
Architecture: all
Depends: ${miscepends}, ${perlepends}, krb5-admin-server, perl,
remctl-server
Description: Provide existing MIT Kerberos keytabs via remctl
keytab-backend is a service that runs under remctld and allows
authenticated clients to download Kerberos keytabs from an MIT Kerberos
KDC without changing the key stored in the Kerberos KDC. It must run on
the same host as the Kerberos KDC and uses kadmin.local to extract the
existing key. It applies additional ACLs to limit which keys may be
extracted in this way. This interface is not needed for Heimdal.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877gs55rmw.fsf@windlord.stanford.edu">http://lists.debian.org/877gs55rmw.fsf@windlord.stanford.edu
 
Old 09-08-2012, 12:36 AM
Lisandro Damián Nicanor Pérez Meyer
 
Default Help me DTRT with upstream naming

On Fri 07 Sep 2012 20:40:07 Russ Allbery escribió:
[snip]
> The second question is: if I should rename it, what should I call it?
> Does anyone have any suggestions that are more unique but that still
> preserve the property of being a reasonably easy-to-remember command-line
> tool for unsophisticated users? I really don't want something like
> "Stanford wallet" because it's intended to be a general, extensible
> solution to enterprise password and key management, and I don't want to
> get into the various trademark issues and so forth that are involved in
> plastering Stanford's name on it.

[Disclaimer: I'm far from being the most suitable person for suggesting this,
but anyway... :-) ]

If you go for changing the name, kerberos-wallet or krb-wallet seems quite
right.

Another quick reduction would be kwallet, but that's already taken... and I
happen to be maintaining it ;-)

Kinds regards, Lisandro.

--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
 
Old 09-08-2012, 12:45 AM
Russ Allbery
 
Default Help me DTRT with upstream naming

Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:

> If you go for changing the name, kerberos-wallet or krb-wallet seems quite
> right.

It's a reasonable idea for the current implementation, but I'd rather not
use that either because the protocol was designed to not require Kerberos.
It currently is only implemented using a remctl protocol, but you could
easily use REST or SOAP to communicate with the backend and 90% of the
software would work without modification. (In fact, in the long run, I
hope to do that sort of implementation, or one that uses ssh public keys
for authentication.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx11cpfh.fsf@windlord.stanford.edu">http://lists.debian.org/87mx11cpfh.fsf@windlord.stanford.edu
 
Old 09-08-2012, 01:11 AM
Lisandro Damián Nicanor Pérez Meyer
 
Default Help me DTRT with upstream naming

On Fri 07 Sep 2012 21:45:54 Russ Allbery escribió:
> Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:
> > If you go for changing the name, kerberos-wallet or krb-wallet seems
> > quite right.
>
> It's a reasonable idea for the current implementation, but I'd rather not
> use that either because the protocol was designed to not require Kerberos.
> It currently is only implemented using a remctl protocol, but you could
> easily use REST or SOAP to communicate with the backend and 90% of the
> software would work without modification. (In fact, in the long run, I
> hope to do that sort of implementation, or one that uses ssh public keys
> for authentication.)

auth-wallet then

Sorry if I'm too nosy :-)

--
"La política es una actividad noble. Hay que revalorizarla, ejerciéndola con
vocación y una dedicación que exige testimonio, martirio, o sea, morir
por el bien común."
Padre Bergoglio - http://www.lanacion.com.ar/1153060

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
 
Old 09-08-2012, 01:21 AM
Henrique de Moraes Holschuh
 
Default Help me DTRT with upstream naming

On Fri, 07 Sep 2012, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri 07 Sep 2012 21:45:54 Russ Allbery escribió:
> > Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:
> > > If you go for changing the name, kerberos-wallet or krb-wallet seems
> > > quite right.
> >
> > It's a reasonable idea for the current implementation, but I'd rather not
> > use that either because the protocol was designed to not require Kerberos.
> > It currently is only implemented using a remctl protocol, but you could
> > easily use REST or SOAP to communicate with the backend and 90% of the
> > software would work without modification. (In fact, in the long run, I
> > hope to do that sort of implementation, or one that uses ssh public keys
> > for authentication.)
>
> auth-wallet then

ticket-master?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908012131.GB27507@khazad-dum.debian.net">http://lists.debian.org/20120908012131.GB27507@khazad-dum.debian.net
 
Old 09-08-2012, 01:33 AM
The Fungi
 
Default Help me DTRT with upstream naming

On 2012-09-07 16:40:07 -0700 (-0700), Russ Allbery wrote:
[...]
> The problem is that the software is called wallet, both the
> software itself and the primary client binary that users invoke.
> [...] I don't think there's another UNIX/Linux binary of that
> name. But, of course, it's still not a very unique name. [...]
> (see the recent node discussion), but on the other hand it's going
> to be a big pain for me and for users
[...]

Frequently invoked console/text utilities have a good excuse for
taking up short, easily typed and easily remembered words in the
executable path namespace. That strikes me as the real reason to
avoid having programs commonly launched from a GUI icon of some sort
polluting that namespace--they aren't frequently called from the
CLI.

If your users are used to entering "wallet blah" and there's no
wallet command in another package already, I'd be in favor of
leaving it as is. Spending most of my life in a CLI, I'm not at all
fond of typing one mile-long-hyphenated-command-name after another.
If you really want to go for something more unique and less of a
common word, then at least go shorter (wlit?).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fungi@yuggoth.org); FINGER(fungi@yuggoth.org);
MUD(kinrui@katarsis.mudpy.org:6669); IRC(fungi@irc.yuggoth.org#ccl); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908013348.GR6169@yuggoth.org">http://lists.debian.org/20120908013348.GR6169@yuggoth.org
 
Old 09-08-2012, 02:11 AM
Matt Zagrabelny
 
Default Help me DTRT with upstream naming

On Fri, Sep 7, 2012 at 8:33 PM, The Fungi <fungi@yuggoth.org> wrote:
> On 2012-09-07 16:40:07 -0700 (-0700), Russ Allbery wrote:
> [...]
>> The problem is that the software is called wallet, both the
>> software itself and the primary client binary that users invoke.
>> [...] I don't think there's another UNIX/Linux binary of that
>> name. But, of course, it's still not a very unique name. [...]
>> (see the recent node discussion), but on the other hand it's going
>> to be a big pain for me and for users
> [...]
>
> Frequently invoked console/text utilities have a good excuse for
> taking up short, easily typed and easily remembered words in the
> executable path namespace. That strikes me as the real reason to
> avoid having programs commonly launched from a GUI icon of some sort
> polluting that namespace--they aren't frequently called from the
> CLI.
>
> If your users are used to entering "wallet blah" and there's no
> wallet command in another package already, I'd be in favor of
> leaving it as is. Spending most of my life in a CLI, I'm not at all
> fond of typing one mile-long-hyphenated-command-name after another.

That is what tab completion is for.

-mz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOLfK3XY+4tk9AyA89REzATEQ0BQSnYXCKK92G3sx0gsqpc_U g@mail.gmail.com">http://lists.debian.org/CAOLfK3XY+4tk9AyA89REzATEQ0BQSnYXCKK92G3sx0gsqpc_U g@mail.gmail.com
 
Old 09-08-2012, 02:18 AM
The Fungi
 
Default Help me DTRT with upstream naming

On 2012-09-07 21:11:51 -0500 (-0500), Matt Zagrabelny wrote:
> That is what tab completion is for.

Granted, but you still have to remember what you're tab-completing,
and tab completion is a bit of a moving target as you add other
packages which install things with somewhat similar names in your
path. If that were really the end-all be-all solution, we'd just get
rid of any sort of execution search path at all and tab-complete
everything to separately installed directory heirarchies so as to
avoid collisions.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fungi@yuggoth.org); FINGER(fungi@yuggoth.org);
MUD(kinrui@katarsis.mudpy.org:6669); IRC(fungi@irc.yuggoth.org#ccl); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908021843.GS6169@yuggoth.org">http://lists.debian.org/20120908021843.GS6169@yuggoth.org
 
Old 09-08-2012, 01:53 PM
Peter Samuelson
 
Default Help me DTRT with upstream naming

[Russ Allbery]
> The problem is that the software is called wallet, both the software
> itself and the primary client binary that users invoke. And, of
> course, we have a bunch of documentation and automation at Stanford
> that assumes that name.

That actually seems like a reasonable name to me. I'm with Jeremy, I
guess, I think normal command-line programs have a little more reason
for shorter and simpler names than GUI and administrative software
does.

Besides, I doubt anybody would prefer that it be called WALL-Et.

(We're not really "helping you DTRT" at all, are we?)

If you rename it at all, I suggest 'nwallet', n for network.

Peter


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908135334.GA6045@p12n.org">http://lists.debian.org/20120908135334.GA6045@p12n.org
 

Thread Tools




All times are GMT. The time now is 07:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org