"nsc generate creds" adds empty line before ------END NATS USER JWT------

[TrinterSoftware]

What version were you using?

2.10.2

What environment was the server running in?

Linux x86_64 native (no docker)

Is this defect reproducible?

nsc generate creds -n

Given the capability you are leveraging, describe your expectation?

generate no empty line before ------END NATS USER JWT------

Given the expectation, what is the defect you are observing?

"nsc generate creds" adds empty line (line break) before ------END NATS USER JWT------
A connection with this JWT is not possible, the server logs an auth error.

[aricart]

@TrinterSoftware what application fails to connect. The formatting for the creds is done by the JWT library, which standardizes on the format.

[TrinterSoftware]

I observed it on two occations:

1. With nats tool I couldn't connect using a context with a .creds file containing that empty line
2. Connection with the GO client failed using that .creds file

[aricart]

I did a quick test:

> nsc generate creds -n U | bat -A -
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ STDIN
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ -----BEGIN·NATS·USER·JWT-----␊
   2   │ eyJ0eXAiOiJKV1QiLCJhbGciOiJlZDI1NTE5LW5rZXkifQ.eyJqdGkiOiJPUDQ1TFJNNFZOQk8zWVNJTUxYRTRKTVY2R0dLT1M0SVE3WEJJNDRGSFpMTDZIRDJRSFNBIiwiaWF0IjoxNzQ
       │ 0NzI2MzE1LCJpc3MiOiJBQ1gzTVZMSE5aNFNKWlFGUjcyRTJSUTdCVUlEVFFBQUZPVUFaTERRN1RLNDRSUzU1T1NWU1dVNSIsIm5hbWUiOiJ1Iiwic3ViIjoiVUJYWU5NQk1ZQTVaNFZYV
       │ jRMNzVCQjNLQkY3WUtBTVM1VjJaV0MyUVJMNVVYRUtESU5GSjI3TlIiLCJuYXRzIjp7InB1YiI6e30sInN1YiI6e30sInN1YnMiOi0xLCJkYXRhIjotMSwicGF5bG9hZCI6LTEsInR5cGU
       │ iOiJ1c2VyIiwidmVyc2lvbiI6Mn19.5jkqBNH7QrJc08RbZ7HPBl2teGSMaPEeGeDp2zbG6WaLMwPS8YWO6BKBTbET7uaLg24sLMfSVBh4SfZa18XODQ␊
   3   │ ------END·NATS·USER·JWT------␊
   4   │ ␊
   5   │ *************************·IMPORTANT·*************************␊
   6   │ NKEY·Seed·printed·below·can·be·used·to·sign·and·prove·identity.␊
   7   │ NKEYs·are·sensitive·and·should·be·treated·as·secrets.␊
   8   │ ␊
   9   │ -----BEGIN·USER·NKEY·SEED-----␊
  10   │ SUALIOPYEJREEYXDPPTJKT3AOK37S5PDEF35PACJRNL3VB6PLYWCOBTFJA␊
  11   │ ------END·USER·NKEY·SEED------␊
  12   │ ␊
  13   │ *************************************************************␊
  14   │ ␊
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

are your files being stored in some sort of shared volume? or something that would muck with line endings - editor?

[TrinterSoftware]

The creds files are stored on the local drive. I used xfce4-terminal:

[aricart]

Looks to me like the xfce4 terminal is doing stuff. Can you try a different terminal or output the creds to a file - nsc generate creds -n service -o /tmp/service.creds

[TrinterSoftware]

With xterm the same, generated file also contains that empty line (I opened the file with mousepad and also printed it with cat).

[TrinterSoftware]

A look with a hex editor shows two times 0x0A:

[aricart]

Is this a particular user creating this situation?

....
00000230: 6834 5366 5a61 3138 584f 4451 0a2d 2d2d  h4SfZa18XODQ.---
00000240: 2d2d 2d45 4e44 204e 4154 5320 5553 4552  ---END NATS USER
00000250: 204a 5754 2d2d 2d2d 2d2d 0a0a 2a2a 2a2a   JWT------..****
00000260: 2a2a 2a2a 2a2a 2a2a 2a2a 2a2a 2a2a 2a2a  ****************
...

[TrinterSoftware]

Yes, it depends on the users. Some have an empty line others not.
All tested users are from one account.

The strange thing is: I have two users, one correct, one with empty line. Both have the same (unlimited) permissions.

[TrinterSoftware]

I've created three new users, all credentials are correct. Maybe it's a problem of an older version.

[aricart]

Can you take a look at the user JWT on disk for that user? is it possible that somehow a rogue newline was added?

[aricart]

I think the JWT for that user was copied from windows or viewed on an editor etc.

[TrinterSoftware]

The creds file for the "service" user on disk und .local/share/nats/nsc/keys/creds/... has no empty line any more, I removed it by hand. When I create new creds for this user, the line shows up again.

I now know how to workaround this. From my perspective you can close this. I opened that ticket only to let you know.

[TrinterSoftware]

The creds file for the "service" user on disk und .local/share/nats/nsc/keys/creds/... has no empty line any more, I removed it by hand. When I create new creds for this user, the line shows up again.

I now know how to workaround this. From my perspective you can close this. I opened that ticket only to let you know.

I didn't read you correctly, you wrote JWT and I thought .creds.
The problematic JWT has an 0x0A at the end, the correct ones dont't have it.

[aricart]

is that JWT super old?

[aricart]

cred generation doesn't regenerate the JWT, it simply copies them into the other document.

[TrinterSoftware]

Thank you for bringing me clarity. It really looks like the JWT file was opened in an text editor.

[TrinterSoftware]

is that JWT super old?

from may 2023

[aricart]

hummm . so possibly some old version of the software was not doing the right thing.