curl -fsSL https://download.jitsi.org/jitsi-key.gpg.key | gpg -o /usr/share/keyrings/jitsy-key.gpg --dearmor
No error messages!

I notice that this is not the same filename as the one in the quote
further above. The original had 'jitsi-keyring.gpg', and this one has 'jitsy-key.gpg' - that's two differences.

(Also, this command line isn't 'including the prompt'.)

This might be an error by me, as there are several names in the different documentations. I rechecked and the names are identical. Maybe a typo here in this mail.

<snip>

And the entry in /etc/apt/sources.list.d/jitsi-stable.list is this:
deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable

This is referencing the original filename, not the one you used in your
"no error messages" command.

Yes, this is the required entry of one of the documentations in the web. As I mentioned before: There are several different instructions, and they are different, as one is for Ubuntu, Ubuntu+Debian and Debian.

Does that file exist? If so, what contents does it have? Are they the
same as the one in the other filename?

Yes, it does exist.

Should be all ok, but it isn't.

If the file named in the sources.list entry doesn't exist (or has the
wrong contents), then I think that would explain it.

Yes, you are correct, but I rechecked. There is "jitsi-keyring.gpg.key", which is from the original jitsi-site, and there is also "jitsi-key.gpg", which is from the jitsi-*keyring*.deb (on the original jitsi-meet website), which I testwise downloaded manually and installed using dpkg.

At the moment, there is only one key existent: jitsi-keyring.gpg.key, which is acually resides in /usr/share/keyrings/.

But I found the reason!

The eys are set "rw- --- ---", so they could not read.

This adds another problem: Looks like gpg or sq is setting wrong rights.

Several minutes ago I discovered another issue: /usr/bin/dpkg was set
to "rwx r-- r--", what is also wrong. As I did not change this, it must have been changed by some upgrade. Had this issue already in 2014 (with a mediathekview problem, same reason),

I suppose, we can safely close this. Thanks for your help, again laerned something.

Best regards

Hans

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sonntag, 22. September 2024, 19:05:35 CEST schrieb Charles Curley:

When you do these things, *exactly* what results do you get? Copy and
paste the entire command line, including the prompt, the results, and
the next command line prompt.

[ … ]

On Sun 22 Sep 2024 at 20:01:02 (+0200), Hans wrote:

But I found the reason!

The eys are set "rw- --- ---", so they could not read.

This adds another problem: Looks like gpg or sq is setting wrong rights.

Several minutes ago I discovered another issue: /usr/bin/dpkg was set
to "rwx r-- r--", what is also wrong. As I did not change this, it must have been changed by some upgrade. Had this issue already in 2014 (with a mediathekview problem, same reason),

I suppose, we can safely close this. Thanks for your help, again laerned something.

From the clues left dotted around, my bet is that you've messed up
your system with the way you become root, affecting its umask.

A couple of months ago (and back in 2020), you were exhorting Debian
to set a mask for users of at least 027, and I'm wondering whether,
in your case, it might have been changed to 077 since around one of
those times.

Back in 2014, you had the permissions on dpkg set to -rwxr-x---,
which would correspond to a umask of 027, so perhaps you had already
tightened your system from the Debian default, 022, to 027 by then.

So it now comes down to why system components are getting the user's
umask applied to them. For that, I looked back to 2014 when you seemed
to be a bit more forthcoming with pasting prompts into your posts.
Your first post in the thread¹ starts with:

| Ok, so let’s start as root:
|
| su -p
| root@protheus2:~# LANG=C mediathekview

Well, three cases of su are:

~$ umask
0027 ← the securer default was set for this user.
~$ su
Password:
/home/auser# umask
0022 ← correct
/home/auser#
exit
~$ su -
Password:
~# umask
0022 ← correct
~#
logout
~$ su -p
Password:
~# umask
0027 ← wrong for root
~#
exit
~$

So I'm guessing that you've been installing things after having become
root with -p. I don't know whether APT and dpkg can themselves modify
any excessively restrictive umask, and I'm unwilling to test that here.

¹ https://lists.debian.org/debian-user/2014/07/msg00053.html

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi David,

this is a very good and value hint! What you are telling is very reasonable and makes fully sense. Yes, in the past I olayed aroud mith umask, and it can really happen, that I messed up things by doing so.

I will recheck my settings and if there are any missettings, of course correct them to debian's actual default settings.

Besides, i am still concerned about the default umask settings, but this I already mentioned and will not be reopened again.

Again: Thank you very much for pointing me to this!

Made me happy!

Best regards

Hans

From the clues left dotted around, my bet is that you've messed up
your system with the way you become root, affecting its umask.

A couple of months ago (and back in 2020), you were exhorting Debian
to set a mask for users of at least 027, and I'm wondering whether,
in your case, it might have been changed to 077 since around one of
those times.

Back in 2014, you had the permissions on dpkg set to -rwxr-x---,
which would correspond to a umask of 027, so perhaps you had already tightened your system from the Debian default, 022, to 027 by then.

So it now comes down to why system components are getting the user's
umask applied to them. For that, I looked back to 2014 when you seemed
to be a bit more forthcoming with pasting prompts into your posts.

Your first post in the thread¹ starts with:
| Ok, so let’s start as root:
|
| su -p
| root@protheus2:~# LANG=C mediathekview

Well, three cases of su are:

~$ umask
0027 ← the securer default was set for this user.
~$ su
Password:
/home/auser# umask
0022 ← correct
/home/auser#
exit
~$ su -
Password:
~# umask
0022 ← correct
~#
logout
~$ su -p
Password:
~# umask
0027 ← wrong for root
~#
exit
~$

So I'm guessing that you've been installing things after having become
root with -p. I don't know whether APT and dpkg can themselves modify
any excessively restrictive umask, and I'm unwilling to test that here.

¹ https://lists.debian.org/debian-user/2014/07/msg00053.html

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)