(In reply to Szabolcs Nagy from comment #16)
> (In reply to Kees Cook from comment #14)
> > So I'd like to bring this back up and reiterate the issue: there is no
> > benefit to the early truncation, and it actively breaks lots of existing
> > software (which is why Debian and Ubuntu have had this fix for 10 years now).
> >
> > What is the _benefit_ of early truncation that justifies breaking so many
> > existing cases?
I wonder if the early truncation was introduced to avoid cases where aliasing can be used to avoid fortify length checks. But then again, truncation might not effectively prevent that after all. And we do not seem to use strlen followed by strcpy in vfprintf.
I haven't looked at this in detail, though.
> ideally sprintf, snprintf and sprintf_chk would be able to share code and
> have identical behaviour (currently there is a lot of duplicated logic in
> glibc with a potential for inconsistent behaviour).
Not sure what you mean by this. The core vfprintf engine is shared, of course.
(In reply to Szabolcs Nagy from comment #16)
> (In reply to Kees Cook from comment #14)
> > So I'd like to bring this back up and reiterate the issue: there is no
> > benefit to the early truncation, and it actively breaks lots of existing
> > software (which is why Debian and Ubuntu have had this fix for 10 years now).
> >
> > What is the _benefit_ of early truncation that justifies breaking so many
> > existing cases?
I wonder if the early truncation was introduced to avoid cases where aliasing can be used to avoid fortify length checks. But then again, truncation might not effectively prevent that after all. And we do not seem to use strlen followed by strcpy in vfprintf.
I haven't looked at this in detail, though.
> ideally sprintf, snprintf and sprintf_chk would be able to share code and
> have identical behaviour (currently there is a lot of duplicated logic in
> glibc with a potential for inconsistent behaviour).
Not sure what you mean by this. The core vfprintf engine is shared, of course.