Bug#666073: heimdal: FTBFS on hurd-i386: MAXHOSTNAMELEN Strikes Back
Package: heimdal
Version: 1.6~git20120311.dfsg.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
currently[1], heimdal 1.6~git20120311.dfsg.1 does not compiled on
hurd-i386.
The problem is a new occurrence of MAXHOSTNAMELEN not covered by patch
041_hurd_maxhostnamelen; the fix (just like the others in that patch)
is to use MaxHostNameLen instead, which is always defined.
Attached there is a new version of patch 041_hurd_maxhostnamelen,
refreshed and with the additional hunk for lib/krb5/principal.c.
[1]
https://buildd.debian.org/status/fetch.php?pkg=heimdalarch=hurd-i386ver=1.6%7Egit20120311.dfsg.1-1stamp=1331734895
Thanks,
--
Pino
--- a/appl/gssmask/gssmask.c
+++ b/appl/gssmask/gssmask.c
@@ -55,7 +55,7 @@ struct client {
struct handle *handles;
struct sockaddr_storage sa;
socklen_t salen;
-char servername[MAXHOSTNAMELEN];
+char servername[MaxHostNameLen];
};
FILE *logfile;
@@ -1097,7 +1097,7 @@ create_client(int fd, int port, const ch
if (moniker) {
c-moniker = estrdup(moniker);
} else {
- char hostname[MAXHOSTNAMELEN];
+ char hostname[MaxHostNameLen];
gethostname(hostname, sizeof(hostname));
ret = asprintf(c-moniker, gssmask: %s:%d, hostname, port);
if (ret == -1)
--- a/appl/kf/kfd.c
+++ b/appl/kf/kfd.c
@@ -128,7 +128,7 @@ proto (int sock, const char *svc)
krb5_ticket *ticket;
char *name;
char ret_string[10];
-char hostname[MAXHOSTNAMELEN];
+char hostname[MaxHostNameLen];
krb5_data data;
krb5_data remotename;
krb5_data tk_file;
--- a/appl/login/login_access.c
+++ b/appl/login/login_access.c
@@ -163,11 +163,11 @@ list_match(char *list,
static char *myhostname(void)
{
-static char name[MAXHOSTNAMELEN + 1] = ;
+static char name[MaxHostNameLen + 1] = ;
if (name[0] == 0) {
gethostname(name, sizeof(name));
- name[MAXHOSTNAMELEN] = 0;
+ name[MaxHostNameLen] = 0;
}
return (name);
}
--- a/appl/test/tcp_server.c
+++ b/appl/test/tcp_server.c
@@ -44,7 +44,7 @@ proto (int sock, const char *service)
krb5_principal server;
krb5_ticket *ticket;
char *name;
-char hostname[MAXHOSTNAMELEN];
+char hostname[MaxHostNameLen];
krb5_data packet;
krb5_data data;
uint32_t len, net_len;
--- a/lib/gssapi/spnego/accept_sec_context.c
+++ b/lib/gssapi/spnego/accept_sec_context.c
@@ -366,7 +366,7 @@ select_mech(OM_uint32 *minor_status, Mec
if (verify_p) {
gss_name_t name = GSS_C_NO_NAME;
gss_buffer_desc namebuf;
- char *str = NULL, *host, hostname[MAXHOSTNAMELEN];
+ char *str = NULL, *host, hostname[MaxHostNameLen];
host = getenv(GSSAPI_SPNEGO_NAME);
if (host == NULL || issuid()) {
--- a/lib/krb5/get_addrs.c
+++ b/lib/krb5/get_addrs.c
@@ -47,7 +47,7 @@ static krb5_error_code
gethostname_fallback (krb5_context context, krb5_addresses *res)
{
krb5_error_code ret;
-char hostname[MAXHOSTNAMELEN];
+char hostname[MaxHostNameLen];
struct hostent *hostent;
if (gethostname (hostname, sizeof(hostname))) {
--- a/lib/krb5/get_host_realm.c
+++ b/lib/krb5/get_host_realm.c
@@ -93,7 +93,7 @@ dns_find_realm(krb5_context context,
krb5_realm **realms)
{
static const char *default_labels[] = { _kerberos, NULL };
-char dom[MAXHOSTNAMELEN];
+char dom[MaxHostNameLen];
struct rk_dns_reply *r;
const char **labels;
char **config_labels;
@@ -221,7 +221,7 @@ krb5_get_host_realm(krb5_context context
krb5_realm **realms)
{
const char *host = targethost;
-char hostname[MAXHOSTNAMELEN];
+char hostname[MaxHostNameLen];
krb5_error_code ret;
int use_dns;
--- a/lib/krb5/krbhst-test.c
+++ b/lib/krb5/krbhst-test.c
@@ -85,7 +85,7 @@ main(int argc, char **argv)
krb5_init_context (context);
for(i = 0; i argc; i++) {
krb5_krbhst_handle handle;
- char host[MAXHOSTNAMELEN];
+ char host[MaxHostNameLen];
for (j = 0; j sizeof(types)/sizeof(*types); ++j) {
printf (%s for %s:\n, type_str[j], argv[i]);
--- a/lib/krb5/krbhst.c
+++ b/lib/krb5/krbhst.c
@@ -1020,7 +1020,7 @@ gethostlist(krb5_context context, const
krb5_error_code ret;
int nhost = 0;
krb5_krbhst_handle handle;
-char host[MAXHOSTNAMELEN];
+char host[MaxHostNameLen];
krb5_krbhst_info *hostinfo;
ret = krb5_krbhst_init(context, realm, type, handle);
--- a/lib/krb5/principal.c
+++ b/lib/krb5/principal.c
@@ -1033,7 +1033,7 @@ krb5_sname_to_principal_old(krb5_context
krb5_principal *ret_princ)
{
krb5_error_code ret;
-char localhost[MAXHOSTNAMELEN];
+char localhost[MaxHostNameLen];
char **realms, *host = NULL;
if(type != KRB5_NT_SRV_HST type != KRB5_NT_UNKNOWN) {
@@ -1188,7 +1188,7 @@ krb5_sname_to_principal(krb5_context con
char *realm, *remote_host;
krb5_error_code ret;
register char *cp;
-char localname[MAXHOSTNAMELEN];
+char localname[MaxHostNameLen];
if ((type != KRB5_NT_UNKNOWN)
(type !=
Bug#666073: heimdal: FTBFS on hurd-i386: MAXHOSTNAMELEN Strikes Back
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2012 02:55 PM, Pino Toscano wrote: Package: heimdal Version: 1.6~git20120311.dfsg.1-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently[1], heimdal 1.6~git20120311.dfsg.1 does not compiled on hurd-i386. The problem is a new occurrence of MAXHOSTNAMELEN not covered by patch 041_hurd_maxhostnamelen; the fix (just like the others in that patch) is to use MaxHostNameLen instead, which is always defined. Attached there is a new version of patch 041_hurd_maxhostnamelen, refreshed and with the additional hunk for lib/krb5/principal.c. [1] https://buildd.debian.org/status/fetch.php?pkg=heimdalarch=hurd-i386ver=1.6%7Egit20120311.dfsg.1-1stamp=1331734895 This change seems fine in general, it's consistent with the rest of the patch. Looking at these patches for the first time, I do wonder if they do the right thing. My understanding is that there is no fixed limit on path and hostnames on GNU/Hurd. Yet MaxHostNameLen and MaxPathNameLen are (fairly arbitrary) constants, meaning that you *do* end up with a limit by using them instead. Wouldn't the proper fix be to use dynamically allocated strings? As using MaxPathNameLen and MaxHostNameLen means there are arbitrary limits anyway, is there any particular reason we couldn't just patch configure to #define MAXHOSTNAMELEN and PATH_MAX if they weren't in limits.h? That seems like a simpler solution and would prevent us from chasing new places where these constants are used. Cheers, Jelmer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPczHnAAoJEACAbyvXKaRXPNoP/i6In1fNLPGmtSZUCKpkv3kD j7/lm1lqgX1XgOjqnTr/Zq9nxRDkV/YkuRjZCOQuv7I7OLBgsyFdRi2czTpda7op w4YXIZd0BPDNv8W3uClv25jl4F3JN+F4VqvSLsC2H6JkNQD5XNsA/mfylBGWWWpL 9NA+QyFu+px3D8IAlxQHOlN81gRvb/cmY2mMXj1qbSincNuQ8ekOkwLib4sx8E7Y 2Knse/OkhXZqswn/P8dFgTBmenwpr1C3eniNkS4/SkWOPMdS3ddjkL1jl9aTzkjm i5VySX0rfHhMXaZewR5xhnoXdW5NF0BE9e8UHQIhCNPb7vBecF6zdDeFpLQKLmpa cEh9kfycRqB24zTkoW7aOlfetw0v61yDcmUoUR21h+NSdQcKKAM00iznGzdS7tGj U4bb78N7umhmvuqJlLp30i41d8Lv1c9V8EnP+v/HiWbee2zi5GVEMd5AI5Y0WOkO 7vOUzu7V0kjbrUrCjsvkDM2XE65oYAmA6nlSU8gPktLD3iLg0EY4MQqawZNY74ra AJC4YiYqp4/4nE3Q4RsnK99r4i+EEPG/oKUkBozfCSX/gmX0yWC4yTm6mXF8MeV/ mYqrq+P27E42BmIvJxSubiTVonRlwnX2lPGe7oWoXnxQWntBSZH1tMi8ODHTs93L ixMXefuPJ35deo1NIxVR =Xh4R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666073: heimdal: FTBFS on hurd-i386: MAXHOSTNAMELEN Strikes Back
Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: On 03/28/2012 02:55 PM, Pino Toscano wrote: Package: heimdal Version: 1.6~git20120311.dfsg.1-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently[1], heimdal 1.6~git20120311.dfsg.1 does not compiled on hurd-i386. The problem is a new occurrence of MAXHOSTNAMELEN not covered by patch 041_hurd_maxhostnamelen; the fix (just like the others in that patch) is to use MaxHostNameLen instead, which is always defined. Attached there is a new version of patch 041_hurd_maxhostnamelen, refreshed and with the additional hunk for lib/krb5/principal.c. [1] https://buildd.debian.org/status/fetch.php?pkg=heimdalarch=hurd-i386 ver=1.6%7Egit20120311.dfsg.1-1stamp=1331734895 This change seems fine in general, it's consistent with the rest of the patch. Thanks. Looking at these patches for the first time, I do wonder if they do the right thing. My understanding is that there is no fixed limit on path and hostnames on GNU/Hurd. Yet MaxHostNameLen and MaxPathNameLen are (fairly arbitrary) constants, meaning that you *do* end up with a limit by using them instead. Wouldn't the proper fix be to use dynamically allocated strings? Yes, the ideal solution would be dynamically allocate strings, either for paths and for hostname strings. Note also MAXHOSTNAMELEN is never used within Linux code (it is only defined to 64 in asm/param.h), so this non POSIX constant is more like an arbitrary limit, even on Linux (maybe it was used in the past, but still didn't make much sense for userland). As using MaxPathNameLen and MaxHostNameLen means there are arbitrary limits anyway, is there any particular reason we couldn't just patch configure to #define MAXHOSTNAMELEN and PATH_MAX if they weren't in limits.h? That seems like a simpler solution and would prevent us from chasing new places where these constants are used. Not sure; as said above, ideally these two constants shouldn't be used (or at most not assume they are always defined, and be able to work as if they wouldn't exist). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#666073: heimdal: FTBFS on hurd-i386: MAXHOSTNAMELEN Strikes Back
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Thanks for the reply. On 03/28/2012 08:39 PM, Pino Toscano wrote: Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: Looking at these patches for the first time, I do wonder if they do the right thing. My understanding is that there is no fixed limit on path and hostnames on GNU/Hurd. Yet MaxHostNameLen and MaxPathNameLen are (fairly arbitrary) constants, meaning that you *do* end up with a limit by using them instead. Wouldn't the proper fix be to use dynamically allocated strings? Yes, the ideal solution would be dynamically allocate strings, either for paths and for hostname strings. Note also MAXHOSTNAMELEN is never used within Linux code (it is only defined to 64 in asm/param.h), so this non POSIX constant is more like an arbitrary limit, even on Linux (maybe it was used in the past, but still didn't make much sense for userland). As far as I can tell POSIX says that the return value of gethostname() is limited to HOST_NAME_MAX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname.html Should we be using that rather than MAXHOSTNAMELEN? As using MaxPathNameLen and MaxHostNameLen means there are arbitrary limits anyway, is there any particular reason we couldn't just patch configure to #define MAXHOSTNAMELEN and PATH_MAX if they weren't in limits.h? That seems like a simpler solution and would prevent us from chasing new places where these constants are used. Not sure; as said above, ideally these two constants shouldn't be used (or at most not assume they are always defined, and be able to work as if they wouldn't exist). It seems simpler to just define them in the source package if they don't exist though, rather than changing all the individual places where they're used. I'll see if I can update the patch. I'm currently also talking to upstream about consistently using either pair of constants; hopefully we'll be able to remove these patches from the Debian package at some point. Cheers, Jelmer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPc3tLAAoJEACAbyvXKaRXN3gP/0eBh+E11HwTciZrP3WSq2Z5 Mh+qQ2rEj50Fru/XQLutkH1ZGc2VHdKLmh4BY6lYcaB8fXzvcQhRzJOuiJQOpqS6 uOCXr6nxUywfTt7PZenhPKaheaO203fZI91bUo3HgicAT8oN00k4WcDJtx2nt0qC NxzwoPtoCsBy7g/SehiFnU6dR4bq4F9Om1ymEFmGyfy1AlXjmfDMYDKExuyuz41v 6/mOJVoVzsRviq/WyOoABMaA0NTAtBnN+e3EwaK8fcjCl9sT1VgGDh/c+49feKZr 4DeskZAncwY/MdQCJ1C9mMm81ZXR3zqbdl7+o2vwoyrvaDHcPjrz04JlfWOburHA StoHZwzgPJuNLaL+7XU4GuQluXJwi/35j7+eL+0JQU7/Y+TX3EVTANwskEASv9/e O9z8sEpNiEP9tTLTThQZZTlNzpUr8IZndOYZAtO9cwxaieq53rngsJ4H2Y8uxLvk S4zngLf00Krp3TYU1GohLUeFf2spqiDm+9JshwiGxawgzUs19ZWpPLd6jHLfrTFQ ZpJwiFrGz0CsRrIUcX7UeO47Ngo8T41JDTiOgkDKTeFNgwK4qgN/5ucdR0vT/xvV SOoC10wxy5rpXwumySfCiZFjMtP5RSaVn6+HiuK/MHYfM25bMPQ7C4DvCfEOAB/X t4Ar8GuVjFvId2dpVITA =Qdi+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666073: heimdal: FTBFS on hurd-i386: MAXHOSTNAMELEN Strikes Back
Hi, Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: On 03/28/2012 08:39 PM, Pino Toscano wrote: Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: Looking at these patches for the first time, I do wonder if they do the right thing. My understanding is that there is no fixed limit on path and hostnames on GNU/Hurd. Yet MaxHostNameLen and MaxPathNameLen are (fairly arbitrary) constants, meaning that you *do* end up with a limit by using them instead. Wouldn't the proper fix be to use dynamically allocated strings? Yes, the ideal solution would be dynamically allocate strings, either for paths and for hostname strings. Note also MAXHOSTNAMELEN is never used within Linux code (it is only defined to 64 in asm/param.h), so this non POSIX constant is more like an arbitrary limit, even on Linux (maybe it was used in the past, but still didn't make much sense for userland). As far as I can tell POSIX says that the return value of gethostname() is limited to HOST_NAME_MAX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname .html Should we be using that rather than MAXHOSTNAMELEN? OTOH, HOST_NAME_MAX (just like PATH_MAX and other _MAX defines) are optional in POSIX, see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html and guess what, there's no HOST_NAME_MAX on Hurd (and not on kFreeBSD either). Interestingly enough, while for POSIX gethostname() never errors out, glibc's implementation can return ENAMETOOLONG if the 'len' argument is smaller than the actual host name length. As using MaxPathNameLen and MaxHostNameLen means there are arbitrary limits anyway, is there any particular reason we couldn't just patch configure to #define MAXHOSTNAMELEN and PATH_MAX if they weren't in limits.h? That seems like a simpler solution and would prevent us from chasing new places where these constants are used. Not sure; as said above, ideally these two constants shouldn't be used (or at most not assume they are always defined, and be able to work as if they wouldn't exist). It seems simpler to just define them in the source package if they don't exist though, rather than changing all the individual places where they're used. I'll see if I can update the patch. I'm currently also talking to upstream about consistently using either pair of constants; hopefully we'll be able to remove these patches from the Debian package at some point. I see, thanks. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
