[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mimelib 1.1.2 packages: strlcpy/strlcat vs. strcpy/strcat



Hi,

On Fri, Apr 24, 2009 at 2:17 AM, Jonas Meurer <jonas@freesources.org> wrote:
> Hello,
>
> I plan to package libmimelib 1.1.2 for debian/unstable. Until now this
> has been built/provided by kdepim from kde3, but as part of the kde4
> transition kdepim3 has been removed from debian/unstable. Still lurker
> depends on libmimelib1c2a, and migrating to libmimelib4 is not an option
> as it would introduce tons of kdelibs dependencies that lurker doesn't
> need at all.
>
> So I copied kdepim-3.5.9/mimelib/ from the kdepim 3.5.9-5 source
> package in order to build a standalone source package from it.
>
> Now I've one problem: kde developers have patched mimelib heavily since
> it has been added to kdepim, and one of the changes is to use
> strlcpy/strlcat at some places.
> Unfortunately, strlcpy/strlcat seems not to be available on a standard
> linux system. Only stncpy/strncat and strcpy/strcat are.
> The original standalone mimelib used strcpy/strcat, but mimelib is in
> fact unmaintained upstream since 1997, so there is no real upstream
> version available. Instead I found more than five different patched
> versions of mimelib in the web, all of them differing a lot.

I am not a Debian Developer, and as a matter of fact this is my very first mail
to this list. But I am a regular programmer, and I shortly looked into this
issue.

Your assumption that strlcpy is not available on a standard Linux system does
not seem to be entirely correct, as the corresponding wikipedia article will
tell you: http://en.wikipedia.org/wiki/Strlcpy

There you can also find a link to an article which gives you some more
background information: http://lwn.net/Articles/33812/

A simple grep -r 'size_t strlcpy' in the source directory of the kernel shows
that the function is indeed defined for the kernel in
"$source/include/linux/string.h" and is implemented in "$source/lib/string.c".

As the wikipedia article also mentions, it is not part of the GNU C library. But
in glib you have a function called g_strlcpy which is a wrapper for strlcpy.

> I would like to package the kdepim 3.5.9 version of mimelib. So what to
> do? As far as I understand, there are three possibilities:
>
> - patch mimelib from kdepim to use strcpy/strcat again, but I guess this
>  is not a good idea as strcpy/strcat seem to be insecure.
>
> - patch mimelib from kdepim to use strncpy/strncat instead of
>  strlcpy/strlcat.
>
> - define strlcpy/strlcat in a custom header file and include that one
>  where appropriate.

I cannot really tell you how this issue should be addressed in Debian, but it
seems to be a known, and rather old issue, so I am sure some DD must know the
proper solution, or rather, the accepted Debian way.

However, from your three proposed options, only the third seems sensible to me,
since the other two would require serious patching in order to keep the code bug
free. I could also imagine that kde defines its own version of the function
somewhere.

Kind regards,
Aljoscha


Reply to: