Re: [Rd] Certificates are not trusted
I checked the installed versions from R-CRAN-kernlab and R-CRAN-tseries R-CRAN-kernlab = 0.9.32 R-CRAN-tseries = 0.10.56 . Updating these packages fails because of incorrect installation Op 15-08-2024 om 14:57 schreef Ben Engbers: Hi, The GPG keys intended for repository ‘Copr repo for cran owned by iucar’ are already installed but not correctly for this package. Check whether the correct key URLs are specified for thiconfigured as: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg Publics repository. Package that failed is: R-CRAN-kernlab-0.9.33-1.fc40.copr7906033.x86_64 GPG keys are key for R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64.rpm is not trusted. Package failed: R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64 GPG keys are configured as: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg The downloaded packages are cached until the next successful transaction. You can delete cached packages by running ‘dnf clean packages’. Error: GPG check failed Ben Engbers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Ben Engbers Grietjeshof 77 6721 VH Bennekom +31 6 23634840 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Certificates are not trusted
Hi, After returning home from holiday I tried to update my Fedora installation with the command 'sudo dnf update -y'. This command now terminates with the following error: error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z Copr repo for cran owned by iucar 11 kB/s | 985 B 00:00 GPG-sleutel op https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg (0x1A3B4456) is al geïnstalleerd error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z error: Verifying a signature using certificate 3124D2EF76DA4D972F6BE4AC9D60CBB71A3B4456 (iucar_cran (None) ): 1. Certificiate 9D60CBB71A3B4456 invalid: certificate is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z 2. Key 9D60CBB71A3B4456 invalid: key is not alive because: The primary key is not live because: Expired on 2024-08-13T00:46:08Z De GPG-sleutels bedoeld voor repository "Copr repo for cran owned by iucar" zijn al geïnstalleerd maar niet correct voor dit pakket. Controleer of de juiste sleutel-URLs voor deze repository zijn opgegeven.. Pakket dat mislukt is: R-CRAN-kernlab-0.9.33-1.fc40.copr7906033.x86_64 GPG-sleutels zijn geconfigureerd als: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg Publieke sleutel voor R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64.rpm is niet vertrouwd. Pakket dat mislukt is: R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64 GPG-sleutels zijn geconfigureerd als: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg De gedownloade pakketten zijn in de cache opgeslagen tot de volgende sucessvolle transactie. Je kan pakketten in de cache verwijderen met het uitvoeren van 'dnf clean packages'. Fout: GPG-check is MISLUKT Deepl translates the last part of this message as: The GPG keys intended for repository ‘Copr repo for cran owned by iucar’ are already installed but not correctly for this package. Check whether the correct key URLs are specified for this repository. Package that failed is: R-CRAN-kernlab-0.9.33-1.fc40.copr7906033.x86_64 GPG keys are configured as: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg Public key for R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64.rpm is not trusted. Package failed: R-CRAN-tseries-0.10.57-1.fc40.copr7906036.x86_64 GPG keys are configured as: https://download.copr.fedorainfracloud.org/results/iucar/cran/pubkey.gpg The downloaded packages are cached until the next successful transaction. You can delete cached packages by running ‘dnf clean packages’. Error: GPG check failed Translated with DeepL.com (free version) How can I renew or update the certificates? Ben Engbers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question on non-blocking socket
Hi Tomas,
Apparently, inserting some kind of socketSelect() is essential when
using non-blocking sockets and a client/erve architecture. That is at
least one thing that I have learned ;-).
In C++, between sending and requesting, I inserted a call to this function:
bool wait(int s) {
fd_set read_set;
struct timeval timeout {};
memset(&timeout, 0, sizeof(timeout));
bool done{};
while (!done ) {
FD_ZERO(&read_set);
FD_SET(s, &read_set);
int rc = select(s + 1, &read_set, NULL, NULL, &timeout);
done = (rc == 1) && FD_ISSET(s, &read_set);
};
return done;
};
Inserting this call was essential in solving my problem.
Ben
Op 15-02-2023 om 17:17 schreef Tomas Kalibera:
In the example you are waiting only for a single byte. But if the
response may be longer, one needs to take into account in the client
that not all bytes of the response may be available right away. One
would keep receiving the data in a loop, as they become available (e.g.
socketSelect() would tell), keep appending them to a buffer, and keep
looking for when they are complete.
Tomas
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question on non-blocking socket
Hi Op 15-02-2023 om 14:38 schreef Tomas Kalibera: On 2/15/23 01:24, Ben Engbers wrote: Hi, December 27, 2021 I started a thread asking for help troubleshooting non-blocking sockets. .. I have two questions. The first is where I can find R documentation on proper use of non-blocking sockets and on the proper use of the socketSelect function? In addition to the demos I sent to you in that 2021 thread on R-pkg-devel, you could also have a look at how it is used in R itself, in the parallel package, in snowSOCK.R, to set up the snow cluster in parallel. Some hints may be also found in the blog post https://blog.r-project.org/2020/03/17/socket-connections-update/. But, in principle, R API is just a thin layer on top of what the OS provides, so general literature and tutorials on sockets should help, there should be even textbooks used at CS universities in networking classes. Thanks for the suggestions! Basically select() can tell you when data is ready (on input), when the socket interface is able to accept more data (on output) or when there is an incoming connection. In practice, you should not need any delays to be inserted in your program to make it work - if that is needed, it means that is an error in it (a race condition). If the program is polling (checking in a loop whether something has already happened, and then sleeping for a short while), the duration of the sleep may indeed influence latency, but should not affect correctness - if it does, there is an error. In RBaseX I first calculate an MD5 hash that is send to the server and then I check the status byte that is returned by the server. writeBin(auth, private$conn) socketSelect(list(conn)) Accepted <- readBin(conn, what = "raw", n = 1) == 0 Without the second line, 'Accepted' is always FALSE. With this line it is TRUE. BaseX provides example API's in several languages. I've looked at several but indeed none uses any form of delay. All API's follow the same pattern, calculate a MD5, send it to the server and check the status byte. So the server is not likely to enforce a delay. So there is nothing left but to look for that racing condition ;-( Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question on non-blocking socket
Hi, December 27, 2021 I started a thread asking for help troubleshooting non-blocking sockets. While developing the RBaseX client, I had issues with the authentication process. It eventually turned out that a short break had to be inserted in this process between sending the credentials to the server and requesting the status. Tomas Kalibera put me on the right track by drawing my attention to the 'socketSelect' function. I don't know exactly the purpose of this function is (the function itself is documented, but I can't find any information for which situations this function should be called.) but it sufficed to call this function once between sending and requesting. I have two questions. The first is where I can find R documentation on proper use of non-blocking sockets and on the proper use of the socketSelect function? The second question is more focused on using non-blocking sockets in general. Is it allowed to execute a read and a receive command immediately after each other or must a short waiting loop be built in. I'm asking this because I'm running into the same problems in a C++ project as I did with RBaseX. Ben Engbers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
