Re: On non-PIC PAM module for OpenSolaris.
Mats Erik Andersson writes:
> @@ -287,6 +282,7 @@ pam_sm_chauthtok (pam_handle_t * pamh, int flags, int
> argc, const char **argv)
>return retval;
> }
>
> +/* Particular to Linux-PAM. */
> #ifdef PAM_STATIC
>
> struct pam_module _pam_shishi_modstruct = {
PAM_STATIC and this _modstruct stuff is not specific to Linux-PAM; it's
also used by FreeBSD PAM. However, the correct way to instantiate it on
FreeBSD is:
#ifdef PAM_MODULE_ENTRY
PAM_MODULE_ENTRY("pam_shishi");
#endif
which takes care of all the structs and whatnot and behaves correctly when
used in combination with PAM_EXTERN on all the pam_sm_* declarations.
I've never seen anyone use this on Linux PAM, although I think it
theoretically supports it. It's more of a FreeBSD thing. I added support
for PAM_EXTERN and PAM_MODULE_ENTRY (if you use those two, you don't have
to explicitly check PAM_STATIC; everything else gets set up for you), but
I was never able to get confirmation from a FreeBSD user that it actually
worked.
Incidentally, this is all a misnomer; on FreeBSD, which is the only place
this stuff appears to be used, none of this actually creates a statically
linked PAM module. (I'm not sure what such a thing would even be.)
Rather, it creates a dynamic module that doesn't export any symbols except
for _pam_shishi_modstruct, which cuts down on symbol leakage.
Other than that, your patch looks good to me.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On non-PIC PAM module for OpenSolaris.
Simon Josefsson writes: > So, is there a standard idiom to turn --with-pic on by default that we > should use? Or just document this fact somewhere? I'm confused about how you have this problem, since by default libtool uses PIC for all shared objects, and I'm not sure why the PAM module wouldn't be a shared object. Oh, I wonder if the problem is just that you're missing -shared in the pam_shishi_la_LDFLAGS setting. You have: pam_shishi_la_LDFLAGS = -module -avoid-version and my PAM module packages all have: pam_krb5_la_LDFLAGS = -module -shared -avoid-version $(VERSION_LDFLAGS) \ $(AM_LDFLAGS) (for example). PAM modules should always be shared; static PAM modules really don't make any sense on nearly all systems. I've never had a request for one in years of maintaining PAM modules. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shisa and its password disclosure.
Mats Erik Andersson writes: > The execution of "shisa -d --keys u...@ex.org" will print the > password in clear text, which I find uncomforting. All the more > so since it is not at all needed in maintaining the keytab file. > I would have expected a dicotomy like used for shadow passwords, > where only a string hash is stored, not the plain text string. It's unusual to actually store the passwords, but Active Directory does so as well because it allows you to do several other interesting things: add new enctypes without forcing a password change, and handle authentication methods other than Kerberos where the authentication server has to know the password and not just a precomputed key. There's no real difference in security within a single realm, although it does mean that one can compromise other authentications for the same user if they reuse a password. > Executing "kadmin.local: getprinc user@SOL" will not reveal the clear > text password, only basic information about the principal. In my > admittedly limited experience with MIT/Solaris, there has never appeared > a means for the administrator to make readable any clear text > passwords. Is there such a command? MIT and Heimdal don't store the password, so indeed you can't retrieve it. (ktadd in both cases can extract the existing key, however, from which you can authenticate as that user just as if you had the password.) Active Directory stores the password, but you have to have a very high level of access to the LDAP store in order to retrieve it. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shisa and its password disclosure.
Mats Erik Andersson writes: > I am somewhat disturbed by that fact that the superuser > is able to execute ># shisa -d --keys > thereby gaining access to all passwords for all principals > of the running KDC. The keys, or the passwords? Not that it probably makes a lot of difference (although only being able to get the keys means that at least it's difficult to attack other realms where the user may reuse the password). > Contrast this to the situation with MIT Kerberos or Heimdal, > where a selected administrator is entrusted with the power to > inspect such secrecies, which the superuser is unable to access, > unless he was able to snoop the administrator's password. The superuser on the KDC can similarly retrieve the keys for any principal in the Kerberos KDC with both MIT and Heimdal, using kadmin -l (Heimdal) or kadmin.local (MIT). It's very difficult in a traditional UNIX security model to protect anything against the superuser, of course. If all else fails, one can always just read the disk database files directly. Improved security probably requires eliminating the traditional security model via something like SELinux. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Put a limit to ticket life span.
Mats Erik Andersson writes: > The patch in this thread intended to address this, and the matter still > is bound by the administrator's decision. Perhaps the factor five should > be replaced by ten as breaking point, but it was chosen as a possible > mode of detecting an exsessive time limit. I do not now for sure. Let me > add that another idea for a solution was stated in [1], but it never > caught any attention. Oh, I see. I'm actually surprised that *all* Kerberos clients don't send an empty ticket lifetime by default. That seems like a sensible thing to do, since then the client gets whatever the server default is. > Luckily, collecting my thoughts for this answer, I have found I third > way of attack, which seems to be what you are looking for. It copes in > the desired way with the Solaris clients, and leaves all other > untouched. Yes, this looks right and like what I would expect (assuming that ticketlife is the server configuration for the maximum ticket life). -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Put a limit to ticket life span.
Mats Erik Andersson writes: > I have brought this up before: > A native Solaris' Kerberos ticket request, will be granted > by "shishid" with a life span of 25 years, since libshishi > does not perform sanitation. It is "shishid" that malfunc- > tions, not the external client! > The following patch resets the requested expiration time for > any request that asks for more than a five-fold of the default > life span, simply by resetting the interval to the configured > default value. I have tested this with "kinit" on OpenIndiana > and "shishid" on Debian. Assuming that I understood this correctly (I've not studied the code) Maximum ticket lifetime should really be something that the KDC administrator can configure, since this is closely tied with local security policies and with the basic security tradeoff of Kerberos (short ticket expirations but no revocation facility). For both MIT and Heimdal, the maximum ticket lifetime is configurable per principal. Assuming 5x the default expiration caps the problem, but isn't the configuration that I suspect most people use. Most sites in my experience set the maximum ticket lifetime to the same as the default and use renewable tickets if they want to allow tickets to last longer than that. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On non-PIC PAM module for OpenSolaris.
Mats Erik Andersson writes: > there is a problem with pam_shishi.so in OpenSolaris > and OpenIndiana. The module builds well with "--with-pic", > but fails completely without PIC. When would you build a non-PIC PAM module for Solaris? I didn't think Solaris supported static PAM modules. In other words, is the actual bug that --with-pic is not the default on Solaris? -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Simon Josefsson writes: > I don't think shishid would ever syslog any passwords. So maybe we > should use LOG_AUTH instead, then? I wonder why LOG_AUTH was marked > deprecated in my man page... I don't know why the Linux manpages project marks LOG_AUTH in general as deprecated. I know that LOG_AUTH on Linux is not configured with restricted access normally, whereas LOG_AUTHPRIV is, but I would still tend to log authentication subsystems (that don't require special permissions) to LOG_AUTH instead of using something generic like LOG_USER. Although I suppose from the perspective of the local system the KDC is just another user process, not part of the authentication infrastructure for that particular system. The GNU C Library manual doesn't document LOG_AUTHPRIV at all and just has LOG_AUTH, so the Linux manpages aren't getting it from there. POSIX itself only standardizes LOG_USER and the LOG_LOCALn priorities and says nothing about any of the other possibilities. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Simon Josefsson writes: > Thanks -- I have changed shishid to use LOG_AUTHPRIV now (we'll see how > portable that is compared to LOG_AUTH...). You should only use LOG_AUTHPRIV for auth logs that have a substantial risk of recording someone's password. I'm not sure if this situation applies. It's normally used by PAM modules, but not by Kerberos KDCs. Anyway, every piece of code I've ever seen that uses LOG_AUTHPRIV has in it something akin to: #ifndef LOG_AUTHPRIV # define LOG_AUTHPRIV LOG_AUTH #endif -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Simon Josefsson writes: > I believe these are important for knowing when someone got a ticket, so > they should definitely be in the syslog. If we are changing this one to > LOG_AUTH, many other messages should also be moved, since they also > print user information. However, I wonder what MIT/Heimdal does, or > what other servers do, like sshd? Heimdal uses LOG_AUTH. I believe MIT does as well, although I'm finding it difficult to locate the exact code that sets the default. sshd uses LOG_AUTH. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#620717: shishi: la file contains non-empty dependency_libs
Simon Josefsson writes: > Hi Russ. I noticed you fixed some things in CVS for the Shishi package, > are you planning to upload that one too? That would be great. Once > that is done, I can import the lenny, squeeze, and your recent upload > into git and upload that to gitorious too, and we continue from there. Yeah, it just went through. Sorry about the delay there; I got caught up in other things yesterday and forgot about it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Simon Josefsson writes: > Which reminds me, now that squeeze is out, we should move the debian > repository to git, and maybe replace cdbs... I will move the repository > to git ASAP since that will make things easier for me. But I'll > probably not have a lot of cycles to replace cdbs -- I don't care > strongly enough; cdbs has "just worked" for me. Moving repositories sounds like a great idea to me. I can take a look at converting to dh, although I agree that it's not that big of a deal since CDBS basically just works. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Simon Josefsson writes: > Simon Josefsson writes: >> I suspect it may be the other way around, but was too tired. I have >> uploaded gss with your fix now (but I forgot to close the bug through >> changelog...). I'll wait a day or two and then fix Shishi too. > The debian copy of my PGP key had expired, the upload is now pending Want me to do the upload, Simon? (If so, anything special I need to know, or just update CVS and build and upload?) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: PacketCable KDC
Simon Josefsson writes: > ale...@sumix.com writes: >> Anybody implemented a PacketCable KDC uses Shishi? Can you help >> configure KDC for Shishi? > I'm not aware of anyone doing this. If you test it, please let us > know. If you can provide access to a PacketCable client, I would be > interested in working on making it work (within reason -- it may be > using a non-standard protocol). To fill in some background, since this also came up on the Heimdal list, PacketCable apparently uses a pre-standardization draft of PKINIT that's not compatible with the standardized final version. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > Sounds almost to good to be true. ;) > > What about all the generated files like PDF manuals? I guess they go > into the xdelta file? The (uncompressed) difference between the version > controlled Shishi source code and the content of a *.tar.gz archive > seems to be about 5MB vs 20MB. The savannah admins' concern was the > size -- I removed around a GB when I removed the old releases of my > projects that were checked into CVS on savannah. So unless I've > misunderstood how pristine-tar works I still think it won't scale. Oh, you do still have to commit the complete upstream release into Git on a separate branch -- that's true. I hadn't realized that you were comparing to only having the upstream distribution repository without the releases and hadn't thought about the generated PDF manuals. Git does have a reasonably efficient delta scheme, but I'm not sure how well it deals with rebuilt PDF files from slightly modified source. > Git is more problematic than CVS here because it will be painful to > remove the xdelta files in the future if we commit them to the upstream > git tree. pristine-tar puts them on a separate branch which you can just delete and then garbage-collect if you decide you don't want to keep them. However, it relies on having a branch that has an import of the upstream release tarball, not just the upstream VC. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > Ok. The savannah admins doesn't want me to put *.tar.gz files into CVS, > so I presume they would have similar feelings about putting *.tar.gz > files into Git, though. So using the upstream source repository for the > debian package files probably won't work out. That's the beauty of pristine-tar. You don't actually commit the full .tar.gz file to Git. You only commit just enough metadata to recreate it from the tagged upstream tree. It's only a checksum and an xdelta file that's usually about 4-16KB. > However, I can use my git.josefsson.org for this. Or does allioth > support git hosting? I'm not sure if I can use it as a DM though. Alioth does support Git hosting. I don't recall if guest accounts can request new projects, but I could certainly request a project, either one for both GSS and Shishi or one for each. Once the project is created, guest accounts have no problem doing everything else with it. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > Great. So, should I upload to unstable or experimental? I'd go for unstable at this point in the release cycle. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > I'm getting close to upload 0.0.38 packages... should I upload to > experimental so you can review the package more easily, or can you > review through the CVS repository and I can upload to unstable? Unless > you want to do the upload, of course. Alas, the CVS repository doesn't > seem to have any tags for the last upload, but you could compare to the > version in lenny. I just reviewed the Shishi packaging (sorry, got distracted last night) and it looks good to me. I also went back and added tags for the previous uploads. Hopefully I remembered how to use CVS properly. I'm too spoiled by Git. :) -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > Yes, but while I have read many blog posts with notes about maintaining > debian packages in git, I haven't see any single complete walk-through > of what I have to do to make that happen. I tried to document what I do at: http://www.eyrie.org/~eagle/notes/debian/git.html Possibly of interest is that I maintain Debian packaging in the same Git repository as upstream development for my own packages, and exactly how to do that is discussed in the document. > It seems there are many variants; some seems to put the entire tar > archives in git which I don't really understand the advantage in. Do > you have some good links? Allowing generation of the upstream tarball from Git is excellent because it makes the Git repository completely stand-alone. All you need is a clone of the repository. You don't need any external data store in order to build packages. The best way to do this is via pristine-tar, which stores only the required extra information to regenerate the exact upstream tarball based on the tagged upstream branch. This is a great tool. The files that it has to store in the repository are usually only a few KB. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Simon Josefsson writes: > Russ Allbery writes: >> You should ideally adjust the 0.0.24 versions to instead be the first >> version at which those symbols existed with their current ABI. It >> doesn't matter a tremendous amount the first time around, though; what >> matters most is how the file is maintained in the future. > The files I downloaded from mole seem to take care of this; it contained > earlier version numbers for most symbols and newer version numbers on > some more recent symbols. Mole should get things mostly correct back to when it first started running. It won't get the versions right before that, but at this point that probably doesn't matter much. > Ok. The advantage for Shishi is probably somewhat questionable right > now, then, but I prefer for my packages to be neat and to implement the > best current practices, so I'll work to make this happen. That's generally the feeling I had about my packages as well. > I'm getting close to upload 0.0.38 packages... should I upload to > experimental so you can review the package more easily, or can you > review through the CVS repository and I can upload to unstable? Unless > you want to do the upload, of course. Alas, the CVS repository doesn't > seem to have any tags for the last upload, but you could compare to the > version in lenny. I can review through the CVS repository, sure. I can also try to add the historic tag based on date stamps. Have you thought about moving to Git for the Debian packaging? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi/GSS no-symbols-control-file lintian warning
Hi Simon, I'm sorry it took me so long to reply to this message. It got stuck in my backlog and got put off due to a very chaotic last quarter of last year. Simon Josefsson writes: > Hi Russ. I am building new Shishi/GSS packages (don't worry, I won't > upload to unstable until after lenny has been released) and ran into: > > I: libgss0: no-symbols-control-file usr/lib/libgss.so.0.0.24 > I tried to read up about this... I am able to generate a symbols list > using 'dpkg-gensymbols -plibgss0 -Ofoo': You should check the generated symbols file against the one that was done in the archive-wide symbols file run by mole: http://qa.debian.org/cgi-bin/mole/seedsymbols/ just to be sure that there aren't any weird architecture-dependent issues, although there shouldn't be for a C library. > However, I haven't found a simple to understand explanation of best > practices on how to modify this file. deb-symbols man page doesn't help > me, nor does <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>. http://wiki.debian.org/UsingSymbolsFiles is the new URL that explains how to implement this. I'm going to add that as an additional reference in Lintian for the no-symbols-control-file tag, since it's somewhat easier to follow than the dpkg-gensymbols(1) man page and includes a link to mole. > I tried to just put the output above into libgss0.dev, however that > resulted in lintian warnings: > E: libgss0: symbols-file-contains-current-version-with-debian-revision on > symbol gss_c_nt_anonym...@base and 90 others > IMHO, dpkg-gensymbols could have avoided adding the -1 itself... > Anyway, I removed the '-1' part in the .symbols file, rebuild the > packages, and now lintian is quiet. The reason why it doesn't do this itself is because it doesn't know for sure when the symbol was introduced (it could have been introduced in a Debian revision), and more fundamentally, what it really would like you to do is update the symbols file to reflect when the symbol first appeared in Debian. The point of symbols files is to allow relaxation of shared library dependencies to make it easier to install binaries that would function properly with older versions of libraries. Currently, in the Debian shlibs system, you have to bump the interpackage dependency whenever a new symbol is introduced, since at that point other packages may start using that symbol and hence require at least that version of the library. Symbols files provide the interpackage dependency system with much more information and allow them to relax the dependency to the first version of the shared library containing all the symbols that theh binary actually uses. This means that introducing a new, infrequently used symbol doesn't cause all packages to have an unnecessarily tight dependency. > However questions remains: > > * Did I do the right thing above? The symbols file is part of > debian-gss CVS if you want to take a look. > * Do I have to modify the file considering that debian unstable contains > 0.0.23 with the same ABI? You should ideally adjust the 0.0.24 versions to instead be the first version at which those symbols existed with their current ABI. It doesn't matter a tremendous amount the first time around, though; what matters most is how the file is maintained in the future. > * What should I do on next release with no ABI changes? Keep the > version number as is in the .symbols file? Correct. The version number indicates the minimum library version required to use that symbol with its current ABI. > * What should I do on next release with ABI changes? Add the new ABI to > the .symbols file with the newer version number? Correct. > * Generally, should I bother with a *.symbols file at all? I get a > feeling from the wiki page that people haven't really decided that > this is the way to go, and I haven't found many debian packages that > use a *.symbols file either. The utility of the symbols file is directly proportional to how many packages depend on that shared library. I plan on introducing them for every package I maintain (with the the exception of C++ libraries) just because they're fairly easy to maintain if you already know how the ABI is changing. But they're particularly valuable for glibc, libpng, and similar libraries that are very widely linked against. I think most of the focus and attention so far has been on those libraries rather than on every library package in Debian. I expect symbols files will get gradually more attention as time goes on. (For example, they're not in Debian Policy yet, and I want to add them.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: debian doc-base sections
Simon Josefsson <[EMAIL PROTECTED]> writes: > I have changed the doc-base sections from (the non-existing) Apps/Net to > System/Security (for the main Shishi manual) and Programming/C (for the > API reference manual). Making this change involved some guess work > based on reading: > > file:///usr/share/doc/doc-base/doc-base.html/ch-interface.html#s-section_field > http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1 > > If anyone have suggestions on better doc-base sections, please let me > know. I'll upload new packages in a few days if I don't hear anything. That sounds right to me. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: debian build of 0.35
Simon Josefsson <[EMAIL PROTECTED]> writes: > It just occurred to me that, with |, couldn't the user have the proper > version of libshishi0 installed, but an old version of, say, > libpam-shishi? The dependencies for shishi-dbg are satisfied via the > proper version of libshishi0, and the incorrect version of libpam-shishi > is not tested. Then debugging of libpam-shishi would fail, potentially > even in bad ways. Yes. Of course, if the user wasn't interested in debugging libpam-shishi, they wouldn't notice. > The dependency relation that we want to express is that if any of the > shishi packages are installed, they must be of the same version as > shishi-dbg, if shishi-dbg is going to be installed. Is that even > possible with dpkg? Only with something like Conflicts, and I think that gets too ugly to be worth it and may lead to aptitude removing the wrong thing. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: debian build of 0.35
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I'm building 0.35 now, to be able to give #423944 back to the inetutils
> package. There are minimal changes compared to 0.34, so it builds fine,
> but I started to look at some of the warnings.
>
> Several of the packages result in:
>
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
>
> Isn't there a ${misc:Depends} variable? Searching on the web yields a
> lot of similar warning messages, but I didn't found how people solved
> it. Should we remove that dependency?
This is a long-standing minor annoyance. The recommendation is generally
to just leave it. Basically: if there is anything that debhelper needs to
do in the maintainer scripts that creates additional dependencies, it will
add those dependencies to ${misc:Depends}. However, if there are none, it
won't create the substvar, and you'll get warnings. So you can remove it
if debhelper isn't creating it, but then if something changes about the
package later and you end up needing those dependencies, you have to add
it back in.
> Then there are a bunch of warnings as below. I suspect these are
> related to
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390882
>
> but I'm not sure whether it is useful to spend time to try to fix this
> for this particular package, as I discussed in that bug report. I don't
> recall seeing the warning from dpkg-shlibdeps before, so maybe there has
> been some policy change in debian?
Indeed, that's the same issue.
The only thing that's changed is that dpkg-shlibdeps now warns.
Otherwise, the situation remains the same.
> I suspect to fully solve this, changes may be needed in the *.la file
> from gnutls, libidn, libtasn1 etc too. Alas, I'm upstream for those as
> well..
Yes, libtool is very bad at handling this since it doesn't have a notion
of libraries needed only for static linking and not for dynamic linking,
and hence includes the full dependency list all the time. For my packages
where I've fixed this, I've had to bypass and not use the libtool *.la
files when linking in order to reduce the dependencies to the required
set.
It's painful to fix.
One possible alternative is to link with --as-needed, although that has
been known to cause problems on some of the more obscure Debian
architectures in the past and to miss dependencies that should still exist
(such as if one uses a data type from another library but not a specific
symbol).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: debian build of 0.35
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Another issue came up when packaging 0.35, lintian complained:
>
> W: shishi-dbg: dbg-package-missing-depends shishi
> N:
> N: This package has a name of the form of "X-dbg", indicating it contains
> N: detached debugging symbols for the package X. If so, it should depend
> N: on the corresponding package, generally with (= ${binary:Version})
> N: since the debugging symbols are only useful with the binaries created
> N: by the same build.
> N:
>
> That was likely because 'shishi-dbg' only depend on libshishi (=
> ${binary:Version}), not the other packages for which it also contains
> debugging information.
>
> I did install the following fix:
>
> -Depends: libshishi0 (= ${binary:Version})
> +Depends: libshishi0 (= ${binary:Version}),
> + libshisa0 (= ${binary:Version}),
> + shishi (= ${binary:Version}),
> + shisa (= ${binary:Version}),
> + shishi-kdc (= ${binary:Version}),
> + libpam-shishi (= ${binary:Version})
>
> But then I realized this probably isn't a good idea... a user should be
> able to install 'shishi-dbg' without having to pull in shishi-kdc etc.
I think that's right, except that you want | instead of , between the
dependencies. That way, the debug package requires at least one package
for which it provides debug symbols to be installed.
I was going to do that when I added the dependency and then didn't.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: GnuTLS and RFC2712?
Simon Josefsson <[EMAIL PROTECTED]> writes: > Btw, Nikos, do you know if there is any license problem to use GPLv3 > code with mod_gnutls? As far as I understand, GPLv3 is compatible with > the Apache license, even though GPLv2 was not compatible. But I may > have missed some point. I believe GPLv3 is compatible with the Apache 2.0 license. The resulting combined work must be distributed under the GPLv3 with the additional restriction clause exercised, as permitted by the GPLv3. The relevant additional restriction added to the license of the combined work is the Apache 2.0 patent provision. This response is based on an answer by RMS to a similar question on another mailing list. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Copy of GFDL in copyright?
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ, I just upgraded debian-shishi CVS for latest Shishi, and also > removed the copy of GFDL and pointed at /usr/share/common-licenses/GFDL > instead. Maybe I shouldn't have done the last step? I noticed your > earlier commit: [...] > I'm not sure I follow the intention: either just the licenses mentioned > in 12.5 are OK to substitute with a reference, or all common licenses > distributed in base-files are OK to substitute with a reference. The > latter seems more flexible to me. Which is it? Policy is currently out of sync with base-files. We'll fix it in the next Policy upload. What you did is fine. > Btw, I suspect we should wait with any upload until the GPLv3 license > has been reviewed by debian, and possibly also installed into > /usr/share/common-licenses/? Yes, that would be my preference. I'm not really sure what that process entails, though, or how long it will take. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#424253: shishi: FTBFS if built twice in a row
Martin Zobel-Helas <[EMAIL PROTECTED]> writes: > Lucas Nussbaum has rebuilt the whole archive on i386 and your package > FTBFS if built twice in a row with the following error: > dh_installudev -pshishi-common > dh_install -pshishi-common > dh_link -pshishi-common > dh_installdocs -pshishi-doc ./README ./NEWS ./AUTHORS ./THANKS doc/shishi.ps > doc/shishi.pdf doc/shishi.html > cp: cannot stat `doc/shishi.ps': No such file or directory > dh_installdocs: command returned error code 256 > make: *** [binary-install/shishi-doc] Error 1 > ** > Build finished at 20070515-1513 > FAILED [dpkg-buildpackage died] > END OF BUILD NO 2 Not sure what's going on here. Clearly something in the clean rule deleted doc/shishi.ps so that it's missing the second time around, but I don't know what. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: krb5dissect
Simon Josefsson <[EMAIL PROTECTED]> writes: > As far as I can tell, 'klist' cannot output: > * raw encryption keys for ccache > * raw krb5 tickets Ah, yes, this is true. And I'm guessing that this probably wouldn't be accepted as a change either, for various reasons. > And generally its output is highly parsed and formatted compared to > krb5dissect which just output the raw contents of the file. Also certainly true. > This discussion has made me realize that perhaps there is some other > potential for krb5dissect, to convert ccache/keytab into a text format > that can be transported, or possibly into/from a standard-format for > transferring credentials (possibly IETF's keyprov, although they seem to > use rather complicated XML to do this). But I'm not sure it will be > anything more than a debug tool to parse ccache/keytab's directly. That would be interesting to me for other reasons. WebAuth currently has to serialize tickets into its token structure, and maintaining that code is remarkably obnoxious and requires significant fiddling between different versions of Kerberos. Unfortunately, it needs to deal with in-memory structures, so something that only reads disk files isn't a lot of help. See: <http://webauth.stanford.edu/protocol.html#krb5token> for the encoding that WebAuth uses. > Also, since the ccache/keytab format isn't a standard, it may be useful > to have a decoder written the way I interpreted the format, and have > 'klist' do whatever MIT thinks it should do. MIT may enhance the > format, and then being able to debug why Shishi doesn't handle new > formats properly may be useful. I certainly agree that having the code available is useful. Separate interoperable implementations are great. I only wasn't sure about the command-line utility itself. > That's very good. Is there any chance your pam_krb5 could become > modular enough so that the krb5-specific calls are isolated and could be > replaced? Or do you think it is not worth the effort? I don't have > resources to work on pam_shishi/krb5 but perhaps a GSOC project is > accepted to modularize pam_krb5 and add Shishi support. I'm not sure. It's borderline. This is difficult to do right now given the number of data structures that Kerberos libraries use and want code to pass around. The hardest part of writing a good abstraction layer over the Kerberos library is dealing with the data structures, not with the API calls. It would certainly require starting with a high-level design and a clear specification of what functionality one needs from the Kerberos layer so that the code didn't make unwarranted assumptions. Adding things like PKINIT support will stress the compatibility layer a lot (MIT's PKINIT branch and Heimdal's release candidates handle PKINIT in entirely different ways). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: krb5dissect
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> Sure, I can sponsor this. I have some other sponsorship requests I >> need to look at first, but I should get to it within a week. > Thanks! If I'm going to rename the tool, you might want to hold off > for a while... Okay, I'll put it on the back burner for a bit. >> I'm not entirely sure that I understand the utility, namely why I would >> ever use this instead of klist, but I guess I see it well enough to be >> willing to upload it. > Krb5dissect is meant as a debug tool, similar to 'dumpasn1' or 'od'. > 'klist' doesn't print all the details in the files. Is this difference primarily when the file is corrupted? (Basically what I'm getting at is that if there's anything in a non-corrupted file that klist isn't already showing, klist should probably be enhanced to do so. Although that doesn't give you information like what format the ticket cache is in, which may indeed be useful, which is why I talked myself into uploading it.) > Perhaps it isn't worth packaging, I guess I got carried away when > creating a new project for this small thing. Creating the Debian > package for it was too simple, I guess. *heh*. It is very addictive. Well, I don't think uploading it with priority extra is really that big of a problem. Having another package in the archive shouldn't really hurt anything. > Still, I know I will find it useful for debugging when I make Shishi use > ccache/keytab's more, which is something I have decided to do. It will > make Shishi work more as a drop-in and avoid users from having to get > the same credentials twice, once for MIT/Heimdal and once for Shishi. I > have to sort out how to work around the limitations of the formats. Incidentally, while I know that Shishi has a different API and therefore there is a good reason for it to have its own PAM module, I'd ideally like to avoid too much duplication of effort around the PAM module design for Kerberos. That's one of the things I tried to fight with my pam-krb5; right now, there are various forks and Sourceforge projects and none of them give you everything that you want. I'm trying to get everything into one module, with all the options that people want, to try to cut down on the confusion. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: krb5dissect
Simon Josefsson <[EMAIL PROTECTED]> writes: > Hi Russ! I've written krb5dissect, from the README: > , > | Krb5dissect is a tool to extract information from Kerberos ccache > | credentials (e.g., /tmp/krb5cc_$UID) or Kerberos keytab credentials > | (e.g., /etc/krb5.keytab). > | > | The ccache format is described in ccache.txt. The ccache.h and > | ccache.c implementation was made for and is used in Shishi, see > | <http://josefsson.org/shishi/>. > | > | The keytab format is described in keytab.txt. > ` > The version 2.1 release contains a debian/ directory and build > lintian-clean Debian packages, and I've filed an ITP #415040 for it. > Homepage: http://josefsson.org/krb5dissect/ > Package: http://josefsson.org/krb5dissect/releases/ > I'm looking for a Debian sponsor for this, do you have time to look at > this one too, Russ? Sure, I can sponsor this. I have some other sponsorship requests I need to look at first, but I should get to it within a week. I'm not entirely sure that I understand the utility, namely why I would ever use this instead of klist, but I guess I see it well enough to be willing to upload it. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#410992: PAM unable to dlopen(/lib/security/pam_shishi.so)
Simon Josefsson <[EMAIL PROTECTED]> writes: > I have built new packages, and they seem correct and lintian clean. > Russ, do you know if we can upload new packages now? I'd say this bug > is 'grave' since it makes the libpam-shishi package unusable, but > upgrading to higher severity level seems controversial. I think it's fine to go ahead and upload packages with this fix. The diff is rather minimal. I'll build and upload new packages now. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian packages of 0.0.29
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> I'm building this now (was on vacation for the past three weeks). > Thanks! I tagged shishi-debian CVS with shishi_0-0-30_1. Bleh, I keep forgetting that. I'm sorry. > Oh, I see. Looks fine now. Btw, I am a bit uncertain about this > part: > Debian packaging copyright: > The package files are copyright 2005, 2006 Simon Josefsson and may > be redistributed and/or modified under the terms of the GNU > General Public License as published by the Free Software > Foundation; either version 2 of the License, or (at your option) > any later version. > Especially given this: > [EMAIL PROTECTED]:~/src/debian-shishi$ cvs log|grep 'author:'|grep -v > 'author: jas' > cvs log: Logging . > date: 2006-11-05 23:35:54 +0100; author: rra; state: Exp; lines: +5 -1 > date: 2006-09-24 05:38:04 +0200; author: rra; state: Exp; lines: +1 -1 Heh. :) Mostly I just made little tweaks, but yeah, I see your point. > Is the following change ok with you? > Debian packaging copyright: > The package files were written by Simon Josefsson and Russ > Allbery, and are copyright 2005, 2006, and may be redistributed > and/or modified under the terms of the GNU General Public License > as published by the Free Software Foundation; either version 2 of > the License, or (at your option) any later version. Sure, that's fine. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian packages of 0.0.29
Simon Josefsson <[EMAIL PROTECTED]> writes: > I've uploaded packages for 0.0.30 now... it should be ready for Debian. I'm building this now (was on vacation for the past three weeks). I looked over debian/copyright and realized that I'd not previously noted that it didn't include a copy of the GNU FDL and instead referenced the copy in the documentation. This is probably fine legally, but Debian Policy requires that all the licenses be present in the copyright file, the only exception being ones that are present in common-licenses. I've therefore included another copy of it in debian/copyright. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes: > On http://bjorn.haxx.se/debian/testing.pl?package=shishi it says: > shishi no longer provides binary shishid. ftpmaster needs to remove it > Is this something that requires manual interaction? No, it happens semi-automatically. (I believe that all of those removals are noted in a file and periodically one of the ftp-masters reviews it and then runs it.) The only time action on the maintainer's part is required is if one is removing a source package entirely. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes: > Do you know if there will be a feature freeze (or similar), for etch, > soon? The etch release schedule, which has slipped somewhat already unfortunately, called for a general freeze in I believe November. So you probably have another month for additional feature development, since it's best to leave a bit of leeway for things to settle before the actual freeze. > There is also my GSS-API library, that uses Shishi. Having that in etch > would be nice. The current released version seems to fail some self > tests, but I'll look into that. I'm happy to upload this as well, sure. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes: > Ok, I now believe debian-shishi is ready for upload, for 0.0.27. It is > lintian clean. Could you take a look? Looks good to me. Uploaded. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Ah, I see. I've seen that in several other packages. I actually
> experimented with that too, but I tried to avoid the hard coded version
> and put some variant of ${Source-Version} or ${source:Version} but it
> didn't work. Is there no way to do this, or did I do something wrong?
Those substitutions only work in debian/control (and only in the binary
package sections of debian/control, for the record).
You can, however, do something like:
version := $(shell dpkg-parsechangelog | grep ^Version: \
| cut -d' ' -f2 | cut -d- -f1)
and then use $(version) in the substitutions. Ugly, but it should work.
> If I bump the major symbol version every time I add a new symbol, which
> is what I believe the libtool manual recommends, I think it would work.
libtool doesn't actually recommend this. The libtool documentation is
just horribly confusing (and I was confused by this part of it for quite
some time). What libtool recommends is that you bump the first number in
the string passed to -version-info. This is *not* the same thing as the
shared library version expressed on disk; libtool derives that version
from the -version-info string using some additional semantics. You'll
discover (at least this is what I've observed in the past) that if you
bump the first number and increment the last number, as the libtool
documentation recommends, libtool *won't* actually increase the major
symbol version.
I wish that libtool hadn't invented its own separate versioning system
that doesn't match the ELF version information in the library, since I
think this confuses a lot of people.
The major version number of a library should not be increased unless the
change would break binaries built against the old library.
> Ah, that was the piece of information I was looking for in the policy
> manual. It described SONAME and similar, but never discussed when it
> must be incremented and when it must not be incremented. I may have
> missed something, though.
The Debian library packaging guide is somewhat more helpful here. See:
<http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes: > Ok. Is it sufficient for shishi-kdc to have: > Package: shishi-kdc > Conflicts: shishid > Replaces: shishid > ? Yup. Or we could even drop that, given that shishid was only ever in unstable as I recall and is now history. > They are typical clients, but so far I haven't paid attention to bump > the library ABI whenever I add new APIs. There has simply been too many > ABI additions so far. Shishi/shisa may use APIs only found in the > latest libshishi. > For example, in the upcoming 'shishi' package, the tool 'keytab2shishi' > uses new APIs in libshishi 0.0.27. So if someone upgrades the 'shishi' > package to 0.0.27 without upgrading 'libshishi0' to 0.0.27, > keytab2shishi won't work. Oh, that's what shlibs is for. Using cdbs, you set DEB_DH_MAKESHLIBS_ARGS_ to the appropriate flags. See the man page for dh_makeshlibs, but basically you want to include a -V flag for each library specifying the last Debian package in which new symbols were added. So, for instance, you probably want: DEB_DH_MAKESHLIBS_ARGS_libshishi0 = -V'libshishi0 (>= 0.0.27)' DEB_DH_MAKESHLIBS_ARGS_libshisa0 = -V'libshisa0 (>= 0.0.27)' Then the right thing will happen with all other packages automatically. > I understand the correct solution is to start using shared library > versioning, but this is some work. Symbol versioning doesn't actually help with this, since the old library doesn't know that you're going to introduce new symbols and couldn't implement them anyway. Tighter dependencies are what is needed here, which is what the Debian shlibs system provides. > Can we solve the problem by using versioning on the Debian packages > instead? Is there any strong policy wording on this? The name of the Debian package should patch the SONAME, which you only need to change if you're removing interfaces or making changes to interfaces that aren't backward-compatible. That deals with the problem of old binaries not working with new libraries, which is the opposite problem of what shlibs deals with. shlibs deals with new binaries not working with old libraries. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian upload of 0.0.27?
Simon Josefsson <[EMAIL PROTECTED]> writes: > I'm preparing the Debian package for 0.0.27. > Would it be OK to drop shishid now? The current package has entered > testing, and been there for a while, and I doubt anyone will install the > old broken packages that only ever were in unstable. Yup, no problem. > I also noticed that 'shishi' and 'shisa' doesn't depend on a particular > version of libshishi0 or libshisa0, see: > http://packages.debian.org/testing/net/shishi > http://packages.debian.org/testing/net/shisa > This is probably a bad idea, I'll try to make the dependency contain > the package version. Hm, so shishi and shisa are not typical clients of those libraries and would be affected by changes to those libraries that other programs linking to those libraries wouldn't care about? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#374288: shishi: FTBFS: Conflicting build dependencies.
Simon Josefsson <[EMAIL PROTECTED]> writes: > Thanks! It seems to have built successfully on most of the problematic > platforms so far... > Btw, I tagged CVS too. Whoops, thanks, I forgot that. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#374288: shishi: FTBFS: Conflicting build dependencies.
Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: >> Once that version enters Debian, we can add libtasn1-3-dev (>= 0.3.5) >> to Shishi's control file, and do another upload of Shishi. It should >> make the self tests work on 64-bit platforms. > The libtasn1 guys were fast! libtasn1 0.3.5 is now in unstable, and > debian-shishi CVS now depend on it. A daily build passes lintian. I > think we could do another upload based on 0.0.26, i.e. 0.0.26-3. Russ? Sorry about the delay. This has finally been uploaded. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#374288: shishi: FTBFS: Conflicting build dependencies.
Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: >> Russ, I think debian-shishi from CVS is ready for another upload. >> Could you take a look? > I just looked at the build logs, and it seems the self tests have > another failure on some platforms. I will look into it. Most likely, > I'll have to release 0.0.27 to fix that... Should I go ahead and upload a 0.0.26-2 to fix the current problem and bug, or wait for you to finish investigating this? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#374288: shishi: FTBFS: Conflicting build dependencies.
Simon Josefsson <[EMAIL PROTECTED]> writes: > Elrond <[EMAIL PROTECTED]> writes: >> Can we make that >> >> libtasn1-3-dev | libtasn1-2-dev >> >> to get a slight chance for backporting? > I've installed this. I assume that libtasn1-3-dev will be the first > choice when Debian's build robots build the package? > Objections to do this from anyone else? Unfortunately, I believe the buildds are allowed to basically pick a random choice among a string of alternatives. (I think the logic goes that the buildd may already have one of the packages installed, and hence the dependency may be satisfied before something like apt gets at it.) It's probably a bit safer to use just the dependency for unstable and ask people doing backports to locally modify the build dependency. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian Shishi integration: GSS-API library
Simon Josefsson <[EMAIL PROTECTED]> writes: > The API is well standardized for years in RFC 2743/2744, so, yes. Well, there are a bunch of portability checks that you need to be able to link against both Heimdal and MIT including older versions, but that's mostly true. I think these are all the compatibility hacks I've had to use in practice: #ifdef HAVE_GSSAPI_H # include #else # include #endif /* Handle compatibility to older versions of MIT Kerberos. */ #ifndef HAVE_GSS_RFC_OIDS # define GSS_C_NT_USER_NAME gss_nt_user_name #endif /* Heimdal provides a nice #define for this. */ #if !HAVE_DECL_GSS_KRB5_MECHANISM # include # define GSS_KRB5_MECHANISM gss_mech_krb5 #endif > The recommended approach to program Shishi is through libgss, since that > makes it easy to swap to any GSS-mech (or at least any GSS-krb5-mech). Yeah, MIT recommends the same. > The few that applications that are using plain kerberos is probably not > worth porting to Shishi. The packages that use plain Kerberos that I personally care about are AFS (via aklog), kstart, and WebAuth. But porting any of those to Shishi isn't really high on my list at the moment. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian Shishi integration: GSS-API library
Simon Josefsson <[EMAIL PROTECTED]> writes: > Supporting this meta-GSS-library approach has been the goal of my GSS > library, but I've noticed that there is another library with a similar > goal that is in the Debian NEW queue, libgssapi from > <http://www.citi.umich.edu/projects/nfsv4/linux/>. > I haven't looked at it in detail though, so I'm not sure it actually > implements this the way I thought it would. Yeah, this was packaged by the NFSv4 folks. I'm not sure if it would work or not, but if it does, it's probably going to get fairly general acceptance. Working with them to make it work may be the path of least resistance to get everyone to rebuild their packages. As the maintainer of a few packages that use GSS-API, I'm interested, and it would also make maintaining Cyrus SASL significantly easier. > There is also a license issue, the libgssapi stuff seem to require > export permissions from the USG to be exported from to U.S., and I'm not > sure if that permissions is granted for exports anywhere, which I would > have a problem with. If that is the case, I'd prefer to improve my GSS > library to make it implement this approach. The export restrictions apply to any code that contains cryptographic code, including the software that you yourself have written if it's brought into the US and then exported again. In other words, this isn't a property of the license on the package, but rather a property of US law that those of us in the US have to deal with and that applies to all packages equally. Thankfully, due largely to the legal work of Dan Bernstein, the US government has a blanket exception for all free software that they wrote into the rules when in imminent danger of losing a Supreme Court free speech decision. So as long as the software is released with source, it's generally not an issue. Debian takes care of all registration requirements for US government export regulations internally, so one doesn't have to worry about this for Debian packages. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian Shishi integration: krb5-config
Elrond <[EMAIL PROTECTED]> writes: > On Wed, May 31, 2006 at 12:30:31PM +0200, Simon Josefsson wrote: >> I've been thinking about integrating Shishi with the rest of Debian >> kerberos stuff. One thing is configuration, and I've looked at the >> krb5-config package. It seems like the shishi-common package could >> depend on it, to ask questions about the default realm and >> KDC/admin-server, and then populate /etc/shishi.conf with the values. > I don't know exactly, if and how debconf supports "other package asks > questions, this package uses answeers" It does, and fairly straightforwardly. You can use debconf as normal in your postinst and just pull the answers from the other package using the regular debconf question designators (which will have a prefix of the other package in this case). I maintain some other packages that do this to share answers across several packages. >> However, it is not implemented yet. One reason is that this seems >> unclean, and I'm worried the /etc/krb5.conf format will change. The >> format isn't really under my control. > I think, that the format is quite stable. mit and heimdal use it. So > both need to cooperate on the issue. Yeah, I think it's fairly unlikely that it will change substantially. MIT is currently considering a profile library rewrite, but it looked like the format that the new library recognized would be almost identical to the old library (only some possible variation in edge cases with whitespace). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Simon Josefsson <[EMAIL PROTECTED]> writes: > Ok, I found it: > http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html > But I realize that I was confused, it doesn't have anything to do with > the NAME variable. > I agree with what you propose, hence I installed the patch below. I > hope it is ready to be uploaded now... Looks good to me. Uploaded. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Simon Josefsson <[EMAIL PROTECTED]> writes: > I built new packages (to add the --make-pidfile flag to > start-stop-daemon --start, because the stop action didn't work), and I > can no longer reproduce the above. I suspected it was caused by having > a MIT KDC running (thus occupying the same ports), but I can't reproduce > that either. O well. > Russ, I'm ready for a new upload. Sorry about the long delay in looking at this. I've been very busy. I was about to upload, but then noticed that NAME in the new shishi-kdc script was set to shishid. That makes sense for the output messages and the PID file, since that's the name of the binary being started, but CDBS installs the init script and defaults file under the name shishi-kdc. Right now, that mismatch means that a few things are wrong and the defaults file doesn't get loaded. I'm not sure on the best solution. Maybe set NAME to shishid as it is now, but not use NAME when loading the defaults file and setting the path to the init script? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Simon Josefsson <[EMAIL PROTECTED]> writes: > Elrond <[EMAIL PROTECTED]> writes: >> It's a well known problem for minimum one year. >> I already ran around "rm /usr/lib/libfoo.la" to get some >> packages building... > The FreeBSD people appear to patch packages to not install *.la too, > which seems like a lot of work... I wonder what the correct upstream > fix would be. Basically, doing the same thing that pkg-config does, namely distinguish between public library dependencies (libraries whose APIs are re-exported by the shared library providing the .la file) and private library dependencies where the linking program doesn't need to and shouldn't link directly with the dependency. Then when libtool is used, you wouldn't need to have the -dev packages for private library dependencies. And as a bonus, libtool wouldn't introduce spurious dependencies in the binary packages, which complicate ABI migrations. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I've also noticed that the libshishi-dev Depends is wrong:
> Depends: libshishi0 (= 0.0.25-1)
> It needs libidn11-dev and libgnutls-dev too, but I'm not sure how to
> make that happen automatically.
Well, it only needs these for static linkage; beyond that, it's a libtool
bug that it attempts to link directly with shared library dependencies
when doing a shared build. pkg-config provides a mechanism to get this
right.
> Similar for libshisa-dev. I'm hard-coding these manually for now.
You have to; there isn't any way to automatically detect dependencies for
-dev packages (at least right now).
> Further Depends problems: I've also made libshishi0 depend on
> a versioned shishi-common:
> -Depends: ${shlibs:Depends}, shishi-common
> +Depends: ${shlibs:Depends}, shishi-common (= ${Source-Version})
> This is because libshishi0 needs the proper locale files from
> shishi-common, mixing versions there is probably not a good idea.
Well, you probably only need shishi-common from the same upstream release,
but yeah, that won't hurt anything and is the simple way of doing it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Elrond <[EMAIL PROTECTED]> writes: > On Tue, May 16, 2006 at 10:35:40PM +0200, Simon Josefsson wrote: >> The problem is, IIUC, that we can't use prerm/postinst to handle an >> old buggy shishid if we at the same time have a shishi-kdc do: >> Provides: shishid >> Conflicts: shishid >> Replaces: shishid >> When I run dist-upgrade, dpkg will use the prerm from the old shishid >> package, which fails, and there is no prerm from the "new" shishid, >> because there is no new shishid. >> One solution I see would be to provide an "empty" shishid with the >> prerm, that depends on shishi-kdc, and remove the above >> Provides/Conflicts/Replaces. > It should have > Replaces: shishid (<= last-version-with-real-shishid) > Conflicts: dito Yup, I'm going to do this in CVS now. Provides is only useful when we don't have an empty transitional package. We won't ever need it. Conflicts indicates that the two packages can't be installed at the same time, so shishid can't conflict with the new -kdc package and still work as a transitional package. shishi-kdc needs to conflict with the previous non-empty shishi package. Replaces indicates that this package contains files that were previously contained in the listed package, so similarly that should have the last shishid before the transitional package. With this change, I think we should be good for an upload. I'll hold off until Simon says we're good, though, just in case. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.26
Simon Josefsson <[EMAIL PROTECTED]> writes: > I can't get automatic upgrade's to work though, when I 'apt-get upgrade' > I don't get the new shishi-kdc, but I'm not sure if this is supposed to > work. Right, that won't work without a transitional package. Hm. We can provide a transitional package and then drop it again before the etch release. > Russ, do you think it is ready for upload? Yup, other than the question of how best to do the transition. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#366526: [mostly-dummy-RC] Don't migrate; changes planned
Simon Josefsson <[EMAIL PROTECTED]> writes: > FYI, today's daily build solves both of these issues: the shishid > package is renamed to shishi-kdc, and there is a libpam-shishi > package. They are lintian clean too. > One question: How to handle the package renaming? Should shishi-kdc > have these fields: > Provides: shishid > Conflicts: shishid > Replaces: shishid > This seems to be the only thing left for 0.0.26 and a new upload. Yup. We can drop those fields after a while since the old package was only in unstable. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> Sure, I'd be happy to do that. (I haven't made any uploads of gss yet -- >> I assume you know that, but just wanted to be clear.) > Great. I have been using the shishi_0-0-25_1 style tags so far. Cool. Do you need me to go back and tag anything that I've already released, or is this for going forward? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > FYI, debian-policy has a changelog entry: > * Bug fix: "init script stop example should use --oknodo", thanks to > Matt Kraai. Removed the example entirely. (Closes: #346598). > And the bug suggest using /etc/init.d/skeleton as the example > instead... There are some difference, notably this block: > ### BEGIN INIT INFO > # Provides: skeleton > # Required-Start:$local_fs $remote_fs > # Required-Stop: $local_fs $remote_fs > # Default-Start: 2 3 4 5 > # Default-Stop: S 0 1 6 > # Short-Description: Example initscript > # Description: This file should be used to construct scripts to be > #placed in /etc/init.d. > ### END INIT INFO > Perhaps we should update the init script... Huh, I've not seen that before. I wonder if that's part of LSB, since it looks a little like the init script headers used in SuSE and Red Hat. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: >> I also note that debian policy has bumped version, I'm updating >> shishi/gss packages with this. > Oops, I noticed you had already done that, thanks! Do you think > tagging CVS when you make an upload would be useful? Sure, I'd be happy to do that. (I haven't made any uploads of gss yet -- I assume you know that, but just wanted to be clear.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 0.0.25
Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: >> Updated debian packages at <http://josefsson.org/shishi/debian/>. I >> think they are ready for upload... whenever you have time, Russ. >> >> Btw, it is not even 'lintian -I -i' clean, after I fixed some man page > ^^^ > Should be 'now', sorry for any confusion... Oh, cool, thanks, I was going to ask about those. I should be able to get to this soon. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > I don't know. Russ, do you know if it is more difficult to change the > package names if it is in testing? If it is the same annoyance, I > think we shouldn't file a rc bug, but let it migrate into testing. It just affects more people. So long as something is only in unstable, I think it's understood that it's under development and such things as package names may change. After it's made it into testing, I tend to be a bit more conservative, since I know that there are some real end users who use testing. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > I think we'll need another upload soon, to fix the library dependency > bug, and if Elrond can confirm that TGS now work against heimdal (and > w2k3?) with all principal names, I'll release 0.0.25 and we can base the > next upload on that. Sounds good? Sounds good to me. > Btw, a while ago I added a 'libgnutls-dev (>= 1.3.5-1+b1)' versioned > build-dependency, probably to fix attempt to fix the linda complaints > about gnutls12 and gnutls13 conflicts. I think those can be safely ignored. > OTOH, perhaps we shouldn't migrate to testing until we've renamed the > package and added the PAM module... Yeah, that's probably not a bad idea, since I'd rather do the package renaming without a transition package and the fewer people are impacted, the better. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Elrond <[EMAIL PROTECTED]> writes: > We could combine the change with an addition of libpam-shishi (from > extras/pam_shishi), so the annoyance for ftp-master is only once? If we did it as part of some other renaming, I would be much less leery of it. (Having this step be manual is actually intentional; one of the things that ftp-masters do is own the overall package namespace and catch obvious problems with package naming or naming transitions that cause trouble for users.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Elrond <[EMAIL PROTECTED]> writes:
> On Tue, Apr 25, 2006 at 11:40:33AM +0200, Simon Josefsson wrote:
>> Ok, good. There isn't a way to only make those parts of the package
>> install process only apply to upgrades from 0.0.23-1, is there?
> dpkg --compare-version.
> grep compare-version /var/lib/dpkg/info/*
> The later will flood you with hundreds of example usages.
You can do something like this if you really want to, but I don't have
0.0.23-1 packages left to test it with any more and wouldn't want to use
it without testing it. I do know that what we have now works since I was
able to test an upgrade from 0.0.23-1 with it.
I'd rather just leave it alone for a few months and then drop it.
# Figure out if we're dealing with the possibly failing case.
ignore=false
if [ "$1" = "failed-upgrade" ] && dpkg --compare-versions "$2" lt "0.0.24" ;
then
ignore=true
fi
maybe_ignore_failure () {
status=$?
if [ "$ignore" = "true" ] ; then
true
else
exit "$status"
fi
}
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Dependency problem?
Russ Allbery <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>> Why doesn't the shishi package automatically depend on libshishi?
>> [EMAIL PROTECTED]:~/src/shishi$ apt-cache show shishi|grep Depend
>> Depends: libc6 (>= 2.3.6-6)
>> [EMAIL PROTECTED]:~/src/shishi$
>> I thought the control file line
>> Depends: ${shlibs:Depends}, ${misc:Depends}
>> would have taken care of that.
> Uh, hm. In order for dh_shlibdeps to pick this up automatically, since
> the library package is built as part of the same source package, it
> needs to have a line like:
> dh_shlibdeps -L libshishi0 -l$(CURDIR)/debian/libshishi0/usr/lib
> to point it to the uninstalled shared libraries.
This would work great if dh_shlibdeps took more than one -L option, but it
doesn't.
However, some other magic is still happening here that causes this to work
provided dh_makeshlibs has already been run for the given library, and I'm
not entirely sure why. That makes me think that the -L option is actually
unnecessary, but the man pages have no hint of that.
Anyway, all this finally reduces to the discovery that the dependencies
are broken unless the libraries are built first, since otherwise
dh_shlibdeps is run for the binary packages before the libraries get
dh_makeshlibs and the libraries are not found. Reordering the packages in
debian/control to put the libraries first fixes the problem.
The mystifying part, though, is that Heimdal uses CDBS, builds tons of
shared libraries, lists them last in debian/control, and doesn't seem to
have this problem. So clearly I'm still missing something somewhere. But
the reordering at least fixes the immediate problem.
I'm pondering what bugs need to be filed. I think there's a cdbs bug here
somewhere and possibly a debhelper bug, but I'm not sure.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Dependency problem?
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Why doesn't the shishi package automatically depend on libshishi?
> [EMAIL PROTECTED]:~/src/shishi$ apt-cache show shishi|grep Depend
> Depends: libc6 (>= 2.3.6-6)
> [EMAIL PROTECTED]:~/src/shishi$
> I thought the control file line
> Depends: ${shlibs:Depends}, ${misc:Depends}
> would have taken care of that.
Uh, hm. In order for dh_shlibdeps to pick this up automatically, since
the library package is built as part of the same source package, it needs
to have a line like:
dh_shlibdeps -L libshishi0 -l$(CURDIR)/debian/libshishi0/usr/lib
to point it to the uninstalled shared libraries. However, this package is
using cdbs, with which I'm not as familiar, so I don't know whether it's
supposed to be doing this magic on its own or requires kicking in some
fashion.
I will go poke at the cdbs documentation and see if I can figure it out.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Elrond <[EMAIL PROTECTED]> writes:
>> While we're still in this phase ("Only unstable has shishi, no
>> debian/stable"):
>> What about renaming shishid to shishi-kdc to get it in line with the
>> other kdc implementations?
>> krb5-kdc - MIT Kerberos key server (KDC)
>> heimdal-kdc - KDC for Heimdal Kerberos
> Makes sense. I guess there should be an empty dummy package, shishid,
> then that is superseded by shishi-kdc, for upgrades? I'll have to read
> up on how that works.
Transitional packages are discouraged for anything that never made it into
stable since it's another package in the archive to keep track of and deal
with. There's probably going to be a little resistance to renaming the
package at this point without some justification, since it does make work
for the ftp-masters re-editing the override files. I'm not sure that I
understand the motivation; if it's to make the package easier to find, I
don't think it will actually help. apt-cache search kdc already finds
shishid due to the KDC line in the description.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Re: cvs notifications
Simon Josefsson <[EMAIL PROTECTED]> writes: > As per > http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pts-cvs-commit > I've asked savannah to forward cvs notifications to the PTS: > https://savannah.gnu.org/support/?func=detailitem&item_id=105319 > If I understand correctly, the notifications won't show up on this > list, but if you are interested, you can subscribe to them through the > PTS. Just FYI, you can subscribe this list to the CVS keyword in the PTS if you want the list to get the notifications (but only that keyword and the others that maintainers don't get by default or you get duplicate mail). It sounds like you don't really want to do that given the shishi-cvs list, but I thought I'd mention just for future reference. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Daily package builder
Elrond <[EMAIL PROTECTED]> writes: > What I often see: 0.0.24cvs20060422-1 (where 0.0.24 is the > last official release), so that the next official release > has a higher number. Ah, yes, the source is actually changing, so this is a better suggestion than mine of putting it into the Debian revision. In theory, all of the packaging tools except for dak itself can now cope with 0.0.25~20060422-1 and will sort that earlier than 0.0.25-1, so you could also try that. Such a version can't currently be uploaded to Debian, but that's possibly even a feature. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Daily package builder
Simon Josefsson <[EMAIL PROTECTED]> writes: > There is now a daily builder of debian packages too, that upload > packages into: > http://josefsson.org/shishi/debian/ > Creating new debian packages is now just one command away for me, so > it should be easy to produce things for Elrond (or others) to test. > Is there some guidelines on daily build package names? Right now I > just use the next's release version (e.g., 0.0.25-1), which should be > safe because we won't package official non-released shishi versions, > but if someone installs a daily build, it will have the same name as > the eventual official ones... I recall some problems with the gnus > daily build debian package names. If you give it the same name as the eventual official ones, the package may not be properly upgraded when the official ones come out. For the most part the packaging tools are fairly good about that, but I wouldn't want to risk it. I'd instead generate a changelog entry (dch may be helpful here) with a version number like 0.0.025-0daily20060423. That will ensure that the version number for each daily build increases, but that they'll all be less than the next official release. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > Thanks! I tagged CVS with shishi_0-0-24_1. > Btw, will we have to keep the prerm/postinst forever? Only until we no longer care about upgrades from 0.0.23. Given that it was the first release and not part of any sort of stable release, we could probably drop them and this modification after a few months. By that point, anyone who was tracking unstable should have upgraded. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > I'm beginning to rethink the idea of disabling shishid by default, I'd > like for 'apt-get install shishid' to install a working and fully > configured shishi KDC. One of my ideas with shishi is that every > machine run its own KDC, and if you have a few more machines, you pool > them together using cross-realm trust. But maybe we can revisit this > later on, too... I think it's okay to leave it started by default. I prefer that anyway; usually when someone installs a daemon package, it's because they want the daemon to run. I've just uploaded 0.0.24-1 with your modifications and a fix for the upgrade problems from 0.0.23-1 when shishid wasn't running. I've tested the latter on my system and it seems to resolve the problem. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: kerberos and ldap: Standards?
Elrond <[EMAIL PROTECTED]> writes: > On Fri, Apr 21, 2006 at 05:32:48PM -0700, Russ Allbery wrote: >> krb5PrincipalName is the RFC-correct attribute to use to store Kerberos >> principal names in an LDAP record. > Thanks. :-) > Just curious: Which RFC is that? Uh... good question. In a quick check, it may be that it's not published in an RFC yet. It is, however, in widespread enough use that I'm quite sure it won't be broken going forward. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: kerberos and ldap: Standards?
Elrond <[EMAIL PROTECTED]> writes: > Say I want to unix user jas to [EMAIL PROTECTED] and unix user elrond to > [EMAIL PROTECTED] > uid: jas > unknown: [EMAIL PROTECTED] > uid: elrond > unknown: [EMAIL PROTECTED] > So what to use for "unknown"? > My current best guess is "krb5PrincipalName". krb5PrincipalName is the RFC-correct attribute to use to store Kerberos principal names in an LDAP record. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > It seems there is a bug in the IPv6 listening code, listening to socket > 0 sounds like listening on stdin, which would explain the Ctrl-D thing. > I'll look into this. > I think shishid should not start by default. Users should enable it > manually so they are sure they know what they are doing. When shishid > is more widely tested, we can revert this behaviour. Okay, I'm going to add an /etc/default/shishid file that sets a variable saying not to start the daemon by default and that users can change to enable automated starting. >> Also, if shishid isn't running, the init script stop action fails > That sounds bad -- IMHO, the stop action shouldn't fail because the > process had already died. > Should we fix the init script here? Yes. --oknodo is needed; I'll add it. > I used the template init script from some Debian manual, so if there is > a problem in it, perhaps we should forward this. Yeah, I'm pondering that. I can see cases where this is desirable (if, for instance, failure to cleanly stop a daemon before upgrading would result in data loss); we just don't happen to have any of those cases. >> which then causes all sorts of strange problems for the upgrade >> process. In fact, if the old shishid package is installed, it appears >> to be impossible to upgrade the system; the package is so broken that >> there doesn't appear to be any way to get rid of it without manually >> removing the init script and then using dpkg --purge >> --force-remove-reinstreq. I think some of this may be due to a >> debhelper bug; I'm investigating. > Yikes, that's really bad. > Disabling shishid by default might fix similar problems in the future. > Removing the init script and invoking the dpkg command works here, so > maybe this should go into the changelog? If we can't find a cleaner > upgrade path, that is. With the help of the debhelper maintainer I have a fix that should work and will be committing to CVS shortly. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Elrond <[EMAIL PROTECTED]> writes: > On Thu, Apr 20, 2006 at 07:33:02PM -0700, Russ Allbery wrote: > [...] >> to be any way to get rid of it without manually removing the init script >> and then using dpkg --purge --force-remove-reinstreq. I think some of >> this may be due to a debhelper bug; I'm investigating. > So if *.24 is anyway in the door, we probably should just > get to *.24 with the next debian upload? Simon's call -- my impression is that it wasn't really released yet. Although with Simon out for a couple of days, I'm probably going to upload a new version this weekend to fix (particularly) the serious bugs in shishid, now that I've figured out how to do that. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Russ Allbery <[EMAIL PROTECTED]> writes: > I'll take a look and see about getting the packages uploaded tomorrow. shishid appears to be broken, at least on my system, and I'm not sure how to fix it. In the current package, the init script starts the daemon in the foreground and it just hangs until one types Ctrl-D. It then dies and the boot process continues. Using --background fixes this, but shishid just starts and immediately exits. It spits out the following in syslog: Apr 20 19:09:08 wanderer /usr/sbin/shishid: Starting (GNUTLS `1.2.9') Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv6:*:kerberos/udp socket 0 Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv4:*:kerberos/tcp socket 4 Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv4:*:kerberos/udp socket 5 Apr 20 19:09:08 wanderer /usr/sbin/shishid: Error reading from IPv6:*:kerberos/udp on socket 0 (-1): Unknown error 4294967295 Apr 20 19:09:08 wanderer /usr/sbin/shishid: Closing IPv6:*:kerberos/udp socket 0 before it disappears. Also, if shishid isn't running, the init script stop action fails, which then causes all sorts of strange problems for the upgrade process. In fact, if the old shishid package is installed, it appears to be impossible to upgrade the system; the package is so broken that there doesn't appear to be any way to get rid of it without manually removing the init script and then using dpkg --purge --force-remove-reinstreq. I think some of this may be due to a debhelper bug; I'm investigating. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > Then the only remaining linda warning was the one about > gnutls12/gnutls13 double dependency. I think I'll ignore that until I > understand exactly what real problem is caused by it. The binaries does > not appear to link to two different libgnutls versions, so I don't see a > problem. At a guess, it's related to some of the other bogus linda checks. linda was using ldd to get library dependency information, which doesn't work. (lintian uses objdump, which is the correct way to do it.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> That should be okay. You need to then list yourself (and anyone else >> who will be making changelog entries, but I can add myself if I end up >> doing that) to the Uploaders field in debian/control, if you haven't >> already. > I put help-shishi@gnu.org as the changelog entry author, is that > incorrect? Must the changelog entry be a person? Yes, that's incorrect. It must be a person. > Having as much automated e-mail go to the list seem better, for future > reference. (Unless it gets too much, but I don't think it will.) No automated mail goes to the author of the changelog entry. The automated mail goes to the package maintainer as listed in debian/control. > Of course, please add yourself, if for nothing else than to test CVS > write access. I'll go ahead and fix. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > The latter sounds best to me, I dislike having any of these discussions > end up in my private mailbox. And if it is publicly archived and open > subscription, we might get more help too. I have changed the control > file to say: > Maintainer: Debian Shishi Team > Ok with everyone? That should be okay. You need to then list yourself (and anyone else who will be making changelog entries, but I can add myself if I end up doing that) to the Uploaders field in debian/control, if you haven't already. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > FYI, lintian -I -i reported: > I: libshishi-dev: arch-dep-package-has-big-usr-share 2548kB 79% > N: > N: The package has a significant amount of architecture-independent data > N: in /usr/share, while it is an architecture-dependent package. This is > N: wasteful of mirror space and bandwidth, as we then end up with > N: multiple copies of this data, one for each architecture. > N: > N: If the data in /usr/share is not architecture-independent, it is a > N: policy violation, and in this case, you should move that data > N: elsewhere. > N: > N: See also: > N: http://www.debian.org/doc/developers-reference/ch-best-pkging-practice > N: s#s-bpp-archindepdata > Which makes sense, so I have moved all man pages from libshishi-dev to > shishi-doc. Sounds good. I'll take a look and see about getting the packages uploaded tomorrow. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > I forgot to run linda/lintian on the new package... it was lintian > clean, but linda complains: > latte:/var/cache/pbuilder/result# lintian -i shishi_0.0.23-2_i386.changes > warning: lintian's authors do not recommend running it with root privileges! > latte:/var/cache/pbuilder/result# linda -i shishi_0.0.23-2_i386.changes > Linda: Running as root, dropping to nobody. > W: shishi-doc; File shishi.devhelp not symlinked to from devhelp dirs > The file shown above exists outside of /usr/share/gtk-doc/html or > /usr/share/devhelp/books, and does not symlink back into either of > those two directories > I don't understand this one, shishi.devhelp _is_ below > /usr/share/gtk-doc/html: > latte:/var/cache/pbuilder/result# dpkg -c shishi-doc_0.0.23-2_all.deb |grep > devhelp > -rw-r--r-- root/root 70676 2006-04-19 12:17:03 > ./usr/share/gtk-doc/html/shishi/shishi.devhelp > -rw-r--r-- root/root 81355 2006-04-19 12:17:03 > ./usr/share/gtk-doc/html/shishi/shishi.devhelp2 > latte:/var/cache/pbuilder/result# > Devhelp appear to find the files correctly. > Is this a linda bug? Yeah, I think so. I don't know a lot about linda, but it sure sounds like one. > W: shishi; A binary links against a library it does not use symbols from > This package contains a binary that links against a library that is > not in the Depends line. This may also be a bug in the library which > does not have a shlibs file. > I don't understand this one. Ignore it. It's broken as designed and apparently will be removed in a future version of linda. > W: shishi-dbg; There is no Depends: line in the control file. > The package has no Depends: line in the control file. This is not > allowed by Policy if the package in question contains binary objects. > Perhaps try calling dpkg-shlibdeps or dh_shlibdeps in the package > rules file. > And this was a linda bug I can ignore, right? Yup. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian shishi package bug
Simon Josefsson <[EMAIL PROTECTED]> writes: > The --background parameter to start-stop-daemon appear to work, and seem > to be the fastest way to solve this problem, so I propose to do it that > way. Do you see any problem with this? I've asked the original > reported to test it. It's fine as a short-term solution; the problem with it in the longer term is described in the start-stop-daemon man page. (It means that the init script can't detect errors in startup.) > Hopefully, shishid in 0.0.24 will support a --nofork parameter, and I > can change the default to fork into the background. > I am sorry for the slow response to this, I have been on vacation. No problem. I had missed it entirely for a while because I forgot to subscribe to the PTS for the package. I've fixed that now. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Debian shishi package bug
There is a serious bug filed against the Debian shishid package saying that shishid doesn't go into the background. This definitely breaks the init script system and needs to be fixed. One can hack around this by telling start-stop-daemon to background the daemon, but really it should background itself. Can this be fixed upstream? I don't see an option telling it to background. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian package issues
Simon Josefsson <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> Simon Josefsson <[EMAIL PROTECTED]> writes: >>> 3) Shishi 0.0.23 is still not released. When some of you have >>>confirmed that you are able to build the package, and doesn't spot >>>any problems, I'll release it and we can produce official Debian >>>packages. >> I'll try to give this a shot later today. Builds fine on AMD64, but I can't get it to work with our realm. I get the following errors: ~> shishi rra libshishi: info: created `/home/eagle/.shishi/shishi.conf' libshishi: warning: /home/eagle/.shishi/tickets: No such file or directory libshishi: warning: Unknown option: `.stanford.edu' Error code from server: Additional pre-authenticationrequired [40] Additional error message from server: NEEDED_PREAUTH shishi: Could not get ticket as `rra' for `krbtgt/stanford.edu'. I customized /etc/shishi/shishi.conf as follows: /etc/shishi# egrep -v '^\#|^$' shishi.conf default-realm=stanford.edu client-kdc-etypes=des-cbc-crc realm-kdc=stanford.edu,krb5auth1.stanford.edu,krb5auth2.stanford.edu,krb5auth3.stanford.edu server-realm=stanford.edu,.stanford.edu stringprocess=UTF-8 Yeah, we have crappy enctypes; fixing that next week. Yes, our realm name is in lowercase. Am I missing something obvious? shishi [EMAIL PROTECTED] produces the same errors. The "Unknown option" error there is particularly mystifying to me. It's clearly complaining about the server-realm setting, but I'm just following the example. (And note the missing space in the pre-auth error.) If Shishi just doesn't implement pre-auth first, then that may be all the issue is and the rest may just be cosmetic. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: New Shishi Debian packages
Yvan Bassuel <[EMAIL PROTECTED]> writes: > - I would have put it into the "doc" section of the control file instead > of leaving the default "net" (ok, I know that kerberos-doc does this...) I admit I'm pretty confused about appropriate use of the doc section, but looking around, I think this is right. I wish there were clearer documentation somewhere about what goes into what section. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian packages ready
Simon Josefsson <[EMAIL PROTECTED]> writes: > I've built new Debian packages for this release, using the latest > debian/ directory from savannah CVS, and placed them at: > http://josefsson.org/shishi/debian/ > Russ, can you upload these files? Or rebuild them yourself if there is > some additional step that is required before making real uploads. I > don't know how Debian uploads really work... Debian packaging rules say that the software needs to be built by the person doing the upload, so what I do is download the .diff.gz, .dsc, and .orig.tar.gz and then rebuild in a chroot. I have now done that and uploaded the packages. You, as the listed maintainer, should get mail shortly for the upload and then later mail saying that the packages are in the NEW queue. There, they have to be reviewed by an ftpmaster since this is the first ever upload of this package. That process can take between a few days and a few weeks. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian package issues
Simon Josefsson <[EMAIL PROTECTED]> writes: > Summarizing the now open issues: > 1) Is it ok to include the GFDL manual now? I have changed the >license so there are no invariant sections. Provided that there are no Invariant Sections, Cover Texts, Acknowledgements, or Dedications (or, alternately, explicit permission to remove them is granted), we're now good and the manual can go into main. > 3) Shishi 0.0.23 is still not released. When some of you have >confirmed that you are able to build the package, and doesn't spot >any problems, I'll release it and we can produce official Debian >packages. I'll try to give this a shot later today. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
