Bug#614562: auth_pass should be up to seven characters long

2011-06-08 Thread Dan Wallis
 For this bug, would the package maintainer be willing to apply
 Vincent's patch (b4d88f76637add8f13d2de2291e4267e0b041a7d, attached)
 to version v1.1.20 in squeeze?

There's a point-release coming up in a couple of weeks. Any chance
this could be done in time?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#614562: auth_pass should be up to seven characters long

2011-06-08 Thread Alexander Wirt
Dan Wallis schrieb am Thursday, den 09. June 2011:

  For this bug, would the package maintainer be willing to apply
  Vincent's patch (b4d88f76637add8f13d2de2291e4267e0b041a7d, attached)
  to version v1.1.20 in squeeze?
 
 There's a point-release coming up in a couple of weeks. Any chance
 this could be done in time?
At least I can try :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#614562: auth_pass should be up to seven characters long

2011-04-07 Thread Vincent Bernat
OoO En  cette aube  naissante du  jeudi 07 avril  2011, vers  07:13, Dan
Wallis mrdanwal...@gmail.com disait :

 Thanks Chris, this bug report saved me some debugging time while
 upgrading half of an LVS pair.

 I've done some digging  testing. From what I can tell, versions up to
 and including v1.1.17 use the first eight characters of auth_pass, and
 from version v1.1.18 only the first seven characters are used (and the
 string is always null-terminated).

 This means that having a really long string for auth_pass is
 redundant, as only the first chunk is used anyway. A password up to
 seven characters works for me across these versions. (Well, v1.1.15
 (lenny) and v1.1.20 (squeeze) actually.)

This bug is fixed in 1.2.1.


pgproIkTRzuAV.pgp
Description: PGP signature


Bug#614562: auth_pass should be up to seven characters long

2011-04-07 Thread Dan Wallis
2011/4/7 Vincent Bernat ber...@debian.org:
 This bug is fixed in 1.2.1.

Great. I found the 1.2 branch in the VCS tree, so can now see what you mean.

For the record, versions prior to v1.1.18 and from v1.2.1 truncate the
password at eight (8) characters, whereas versions v1.1.18 through
v1.2.0 truncate the password at seven (7) characters.

I've submitted a patch upstream to get this added to the manual page
for keepalived.conf(5) to reflect this truncation/limit.


For this bug, would the package maintainer be willing to apply
Vincent's patch (b4d88f76637add8f13d2de2291e4267e0b041a7d, attached)
to version v1.1.20 in squeeze?
commit b4d88f76637add8f13d2de2291e4267e0b041a7d
Author: Vincent Bernat ber...@luffy.cx
Date:   Sat May 15 11:34:28 2010 +

VRRP: handle passwords up to 8 characters

A fix in keepalived 1.1.18 was truncating the password len for VRRP to
7 characters. We restore the limit to 8 characters.

vrrp-auth_data is only handled using memcpy and sizeof. Therefore, we
keep the current size to 8 chars and add the null character only when
we need to display it.

Also, we ensure that vrrp-auth_data is blanked before putting a new
value in it, just for safety.

diff --git a/keepalived/vrrp/vrrp_data.c b/keepalived/vrrp/vrrp_data.c
index 98676cc..0512417 100644
--- a/keepalived/vrrp/vrrp_data.c
+++ b/keepalived/vrrp/vrrp_data.c
@@ -192,6 +192,7 @@ static void
 dump_vrrp(void *data)
 {
 	vrrp_rt *vrrp = data;
+	char auth_data[sizeof(vrrp-auth_data) + 1];
 
 	log_message(LOG_INFO,  VRRP Instance = %s, vrrp-iname);
 	if (vrrp-family == AF_INET6)
@@ -225,7 +226,10 @@ dump_vrrp(void *data)
 		log_message(LOG_INFO,Authentication type = %s,
 		   (vrrp-auth_type ==
 			VRRP_AUTH_AH) ? IPSEC_AH : SIMPLE_PASSWORD);
-		log_message(LOG_INFO,Password = %s, vrrp-auth_data);
+		/* vrrp-auth_data is not \0 terminated */
+		memcpy(auth_data, vrrp-auth_data, sizeof(vrrp-auth_data));
+		auth_data[sizeof(vrrp-auth_data)] = '\0';
+		log_message(LOG_INFO,Password = %s, auth_data);
 	}
 	if (!LIST_ISEMPTY(vrrp-track_ifp)) {
 		log_message(LOG_INFO,Tracked interfaces = %d, LIST_SIZE(vrrp-track_ifp));
diff --git a/keepalived/vrrp/vrrp_parser.c b/keepalived/vrrp/vrrp_parser.c
index 3840073..b2295e9 100644
--- a/keepalived/vrrp/vrrp_parser.c
+++ b/keepalived/vrrp/vrrp_parser.c
@@ -306,11 +306,11 @@ vrrp_auth_pass_handler(vector strvec)
 	int max_size = sizeof (vrrp-auth_data);
 	int str_len = strlen(str);
 
-	if (str_len  max_size - 1)
-		str_len = max_size - 1;
+	if (str_len  max_size)
+		str_len = max_size;
 
+	memset(vrrp-auth_data, 0, max_size);
 	memcpy(vrrp-auth_data, str, str_len);
-	vrrp-auth_data[str_len] = '\0';
 }
 static void
 vrrp_vip_handler(vector strvec)


Bug#614562: auth_pass should be up to seven characters long

2011-04-06 Thread Dan Wallis
Thanks Chris, this bug report saved me some debugging time while
upgrading half of an LVS pair.

I've done some digging  testing. From what I can tell, versions up to
and including v1.1.17 use the first eight characters of auth_pass, and
from version v1.1.18 only the first seven characters are used (and the
string is always null-terminated).

This means that having a really long string for auth_pass is
redundant, as only the first chunk is used anyway. A password up to
seven characters works for me across these versions. (Well, v1.1.15
(lenny) and v1.1.20 (squeeze) actually.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org