On 9 August 2018 at 17:28, Kalle Valo [off-list ref] wrote:

Michael B=C3=BCsch [off-list ref] writes:

quoted

strncpy might not NUL-terminate the string, if the name equals the buffe=

r size.

quoted

Use strlcpy instead.

Signed-off-by: Michael Buesch <m@bues.ch>
Cc: stable@vger.kernel.org

This is weird, with all the patches you submitted last week I get this
if I download the patch from patchwork:

$ git am -s 1.mbox
Patch is empty. Was it split wrong?

But if I download the patch directly from my IMAP folder I have no
problems:

$ git am -s 1.mbox
Applying: b43/leds: Ensure NUL-termination of LED name string

This happens even without my custom patchwork script so this has
something to do with the patchwork server, but it's not obvious to me
what triggers it. IIRC I have not seen anything like this before. It
seems that you didn't use git-send-email, I strongly suggest to use that
just to avoid problems like this.

Looks like patchwork mishandles the pgp signature, the patchwork mbox has

Content-Type: multipart/signed; micalg=3Dpgp-sha512;
 boundary=3D"Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol=3D"application/pgp-s=

ignature"

as the only content-type (and the boundary is nowhere to be found),
while the one in my inbox has

Content-Type: multipart/signed; micalg=3Dpgp-sha512; boundary=3D"Sig_/EN9=

0ciRq4eWXDUcnZABQ0Ak"; protocol=3D"application/pgp-signature"

--Sig_/EN90ciRq4eWXDUcnZABQ0Ak
Content-Type: text/plain; charset=3DUS-ASCII
Content-Transfer-Encoding: quoted-printable

When I remove the Content-Type: line(s) from the mbox from patchwork,
git recognises it again as a patch. I guess git am ignores everything
until the boundary, which got dropped by patchwork, so it never finds
the actual patch.


Regards
Jonas