Jonas Gorski <jonas.gorski@xxxxxxxxx> writes: > 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. Awesome, thanks for debugging this! It would be great if someone could report this to the patchwork maintainers, I don't have the time right now. -- Kalle Valo
