fix carriage-return in key files

[obezpalko]

if header starts with "-----BEGIN OPENSSH PRIVATE KEY-----\r\n" - it will not break the key loading the same for the end marker. even for the case "-----BEGIN OPENSSH PRIVATE KEY-----\EOF" both \r & \n are ignoring on the key loading

[kalvdans]

Wouldn't your suggestion print the mark and the first line of the key on the same line? This is the code I'm refering to:

	/* assemble uuencoded key */
	if ((r = sshbuf_put(blob, MARK_BEGIN, MARK_BEGIN_LEN)) != 0 ||
	    (r = sshbuf_dtob64(encoded, blob, 1)) != 0 ||
	    (r = sshbuf_put(blob, MARK_END, MARK_END_LEN)) != 0)
		goto out;

[obezpalko]

Wouldn't your suggestion print the mark and the first line of the key on the same line? This is the code I'm refering to:

	/* assemble uuencoded key */
	if ((r = sshbuf_put(blob, MARK_BEGIN, MARK_BEGIN_LEN)) != 0 ||
	    (r = sshbuf_dtob64(encoded, blob, 1)) != 0 ||
	    (r = sshbuf_put(blob, MARK_END, MARK_END_LEN)) != 0)
		goto out;

The problem is not in assembling keys, but in parsing. In case if You upload key with http-form all \n will be converted to \r\n and reading parser will not catch the key blok boundaries.

[kalvdans]

The problem is not in assembling keys, but in parsing.

Ah true. I just wanted to clarify that we shouldn't merge your PR in its current form.

[obezpalko]

I just wanted to clarify that we shouldn't merge your PR in its current form.

is something wrong with it?

[kalvdans]

is something wrong with it?

Yes, printing out a key no longer adds newline between the header and the first row of base64 data.

[obezpalko]

@kalvdans

It seems I got the point.

~~printing is ok~~ ~~but this is not about printing.~~ ~~\r\n can appear in file if You edit it in windows-mode or upload via http form.~~ ~~This is OK for base64 section, but after this edit/upload key file becomes not valid and it's hard to detect why~~