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: ${shlibs:Depends}, ${misc:Depends}
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: ${misc:Depends}, ${perl:Depends}, 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: ${misc:Depends}, ${perl:Depends}, 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/>
Reply to: