Bug 2144014

Hello, I am still trying to reproduce this, but those invalid JSON messages look suspicious; could please run something like this in the server, to check whether the files are valid JSON files?

# jose fmt --json <full file path>

Something like this, if the paths in your example are correct:

# jose fmt --json /var/db/tang/blah-sig-2022-05-29.jwk
# jose fmt --json /var/db/tang/blah-exc-2022-05-29.jwk

(additionally, feel free to run this using any other files you find under /var/db/tang/)

You should see no output, if the files are valid JSON files, which is what we expect here; in case they fail to validate, you should see "Invalid json!" followed by some "jose fmt" usage information.

jose fmt --json does not report any issue for any of the files in /var/db/tang.

I use tcpdump to capture the POST request on and then use jose fmt --json to
parse the on-the-wire message. It also report no issue.

I think I am going to need to build tangd and add in debug support to see the exact
bytes that are being processed in the code. And if that is not helping I think I'll
have to add debug code to the json library.

I'm running tang on a RPi 4 and its on port 2269.

I added a patch to print the error details in keys.c from the call to json_load_file.

        if (strcmp(dot, pattern) == 0) {
            json_error_t error;

            /* Found a file with .jwk extension. */
            if (snprintf(filepath, PATH_MAX, "%s/%s", jwkdir, d->d_name) < 0) {
                fprintf(stderr, "Unable to prepare variable with file full path (%s); skipping\n", d->d_name);
                continue;
            }
            filepath[sizeof(filepath) - 1] = '\0';
            json_auto_t* json = json_load_file(filepath, 0, &error);
            if (!json) {
                enum json_error_code code = json_error_code(&error);
                fprintf(stderr, "Invalid JSON file (%s); skipping\n", filepath);
                fprintf(stderr, "code %d text %s line %d col %d pos %d",
                    code, error.text, error.line, error.column, error.position);
                continue;
            }

Then I see this in the journal (qqq replaces possibly sensitive info):

Nov 23 16:00:35 clef.chelsea.private tangd[12406]: 172.16.2.175 POST /rec/qqqq Invalid JSON file (/var/db/tang/qqq.jwk); skipping
Nov 23 16:00:35 clef.chelsea.private tangd[12406]: code 3 text unable to open /var/db/tang/qqq.jwk: Permission denied line -1 col -1 pos 0Invalid JSON file (/var/db/tang/qqq.jwk); skipping

So... I know what to fix now. I have no idea why the permissions changed on the upgrade.

I recommend adding the error info to tang.
Do you want a PR for this? Where should I do that? I think you are upstream maintainer.

Barry

(In reply to Barry Scott from comment #3)

[...]

> So... I know what to fix now. I have no idea why the permissions changed on
> the upgrade.
> 

Thanks for the investigation, but what was this upgrade again? Were you upgrading from tang-10?

> I recommend adding the error info to tang.
> Do you want a PR for this? Where should I do that? I think you are upstream
> maintainer.
> 

Sure, if you can submit a PR at [1] it would much be appreciated. It would be very helpful to have a more specific error message for this case.

[1] https://github.com/latchset/tang

(In reply to Sergio Correia from comment #4)

> Thanks for the investigation, but what was this upgrade again? Were you
> upgrading from tang-10?

# dnf history info tang | grep tang
Command Line   : reinstall ./tang-11-4.fc37.aarch64.rpm
    Reinstall   tang-11-4.fc37.aarch64 @@commandline
    Reinstalled tang-11-4.fc37.aarch64 @@System
    Upgrade    tang-11-4.fc37.aarch64                                      @fedora
    Upgraded   tang-11-3.fc36.aarch64                                      @@System
Command Line   : update tang
    Upgrade  tang-11-3.fc36.aarch64 @updates
    Upgraded tang-11-2.fc36.aarch64 @@System
Command Line   : downgrade tang
    Downgrade  tang-11-2.fc36.aarch64 @fedora
    Downgraded tang-11-3.fc36.aarch64 @@System
    Upgrade       tang-11-3.fc36.aarch64                                      @updates
    Upgraded      tang-11-2.fc36.aarch64                                      @@System
Command Line   : install tang
    Install tang-11-2.fc36.aarch64           @fedora

I'm using an RPi4 as my key server. Its not full disk encrypted so I added a
use a small LUKS partition to hold the keys.

# lsblk --fs
NAME          FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
mmcblk0
├─mmcblk0p1   vfat        FAT32       4F15-340F                             568.2M     5% /boot/efi
├─mmcblk0p2   ext4        1.0         ddaaada4-49ce-4a70-bf1f-19f5af8ced90  772.9M    14% /boot
├─mmcblk0p3   ext4        1.0         0cf3008c-e4cd-461e-a3d4-b882a513fba7    1.5G    59% /
├─mmcblk0p4
└─mmcblk0p5   crypto_LUKS 2           fbba9e51-bed1-450f-a991-6e9efc403d5b
  └─key-vault ext3        1.0         da052fce-5f54-4ea7-b5fa-9c14a54c112b     69M     0% /var/lib/key-vault
zram0                                                                                     [SWAP]
# ls -l /var/db/tang
lrwxrwxrwx. 1 tang tang 23 Sep  8 12:38 /var/db/tang -> /var/lib/key-vault/tang

The fix was to chown the exc and sig from root:root to tang:tang.

The upgrade to f37 sequence was:
1. upgrade f36 to latest
2. test tang working
3. system-upgrade to f37
4. test tang working
5. report this issue

> Sure, if you can submit a PR at [1] it would much be appreciated. It would
> be very helpful to have a more specific error message for this case.
> 
> [1] https://github.com/latchset/tang

Will do.

https://github.com/latchset/tang/pull/103

FEDORA-2022-de24665e71 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-de24665e71

FEDORA-2022-3c3a91e691 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3c3a91e691

FEDORA-2022-92367a781f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-92367a781f

FEDORA-2022-de24665e71 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-de24665e71`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-de24665e71

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-3c3a91e691 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-3c3a91e691`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3c3a91e691

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-92367a781f has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-3c3a91e691 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-de24665e71 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.