On 9 August 2018 at 17:28, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: > Michael Büsch <m@xxxxxxx> writes: > >> strncpy might not NUL-terminate the string, if the name equals the buffer size. >> Use strlcpy instead. >> >> Signed-off-by: Michael Buesch <m@xxxxxxx> >> Cc: stable@xxxxxxxxxxxxxxx > > 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=pgp-sha512; > boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" 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=pgp-sha512; boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" > > --Sig_/EN90ciRq4eWXDUcnZABQ0Ak > Content-Type: text/plain; charset=US-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
