Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
Mark Geisert wrote: This allows correct copy and pasting between the two Cygwin flavors. [...] Eh, that's a bad patch. Don't apply. It's OK for concept review. v2 forthcoming. Thanks, ..mark
[PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
This allows correct copy and pasting between the two Cygwin flavors.
What's done is to overlay the differing timespec formats via a union
within the control structure cygcb_t. Then conversion between the two
formats is done on the 32-bit side only.
The cygutils package has two programs, putclip and getclip, that also
depend on the layout of the cygcb_t. At present they have duplicate
defs of struct cygcb_t defined here as no Cygwin header provides it.
---
winsup/cygwin/fhandler_clipboard.cc | 39 +
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..649e57072 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -28,9 +28,16 @@ static const WCHAR *CYGWIN_NATIVE =
L"CYGWIN_NATIVE_CLIPBOARD";
typedef struct
{
- timestruc_t timestamp;
- size_t len;
- char data[1];
+ union
+ {
+struct timespec ts; // 8 bytes on 32-bit Cygwin, 16 bytes on 64-bit Cygwin
+struct
+{
+ uint64_t cb_sec;
+ uint64_t cb_nsec;
+};
+ };
+ uint64_t cb_size;
} cygcb_t;
fhandler_dev_clipboard::fhandler_dev_clipboard ()
@@ -74,9 +81,14 @@ fhandler_dev_clipboard::set_clipboard (const void *buf,
size_t len)
}
clipbuf = (cygcb_t *) GlobalLock (hmem);
- clock_gettime (CLOCK_REALTIME, >timestamp);
- clipbuf->len = len;
- memcpy (clipbuf->data, buf, len);
+ clock_gettime (CLOCK_REALTIME, >ts);
+#ifndef __x86_64__
+ // expand 32-bit timespec layout to 64-bit layout
+ clipbuf->cb_nsec = clipbuf->ts.tv_nsec;
+ clipbuf->cb_sec = clipbuf->ts.tv_sec;
+#endif
+ clipbuf->cb_size = len;
+ memcpy ([1], buf, len); // append data
GlobalUnlock (hmem);
EmptyClipboard ();
@@ -179,8 +191,13 @@ fhandler_dev_clipboard::fstat (struct stat *buf)
&& (hglb = GetClipboardData (format))
&& (clipbuf = (cygcb_t *) GlobalLock (hglb)))
{
- buf->st_atim = buf->st_mtim = clipbuf->timestamp;
- buf->st_size = clipbuf->len;
+#ifndef __x86_64__
+ // compress 64-bit timespec layout to 32-bit layout
+ clipbuf->ts.tv_sec = clipbuf->cb_sec;
+ clipbuf->ts.tv_nsec = clipbuf->cb_nsec;
+#endif
+ buf->st_atim = buf->st_mtim = clipbuf->ts;
+ buf->st_size = clipbuf->cb_size;
GlobalUnlock (hglb);
}
CloseClipboard ();
@@ -218,10 +235,10 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
{
cygcb_t *clipbuf = (cygcb_t *) cb_data;
- if (pos < (off_t) clipbuf->len)
+ if (pos < (off_t) clipbuf->cb_size)
{
- ret = ((len > (clipbuf->len - pos)) ? (clipbuf->len - pos) : len);
- memcpy (ptr, clipbuf->data + pos , ret);
+ ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
+ memcpy (ptr, [1] + pos , ret);
pos += ret;
}
}
--
2.33.0
Re: Lighttpd and Perl
Hi again, Thanks for the pro tip. I am trying to register with the lighttpd forum, but the activation email has yet to make it to my inbox. Any tips? Thanks, -Andy > On Sep 30, 2021, at 4:28 PM, gs-cygwin@gluelogic.com wrote: > > On Thu, Sep 30, 2021 at 10:07:24AM +, Andy Romens via Cygwin wrote: >> Good morning all, >> >> I am running into a bit of what appears a noob issue with lighttpd. >> >> Short and sweet version is I am transitioning from Apache to lighttpd. >> >> Gotten pretty far, except now I am having issues with parsing. >> >> Our website will run a command in a browser like >> ‘server/cgi-bin/myscript.pl?prod,eventhist’ in the web browser. With Apache, >> it will split everything after the ‘?’ As variables, and return a nicely >> formatted html result page. >> >> However, after switching to lighttpd, it’s not passing those variables >> anymore. When I run the script in Cygwin, it works just fine. >> >> I’ve been banging my head on this problem for a few days now, so any >> assistance would be greatly appreciated. > > I'd suggest starting at > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.lighttpd.net%2F%23Documentationdata=04%7C01%7C%7C722d1ee7355143db178608d9845939b8%7C84df9e7fe9f640afb435%7C1%7C0%7C637686341017068026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hSrAta1EEh35EgYUBixhVNG%2FWc8jbg94uM3mwrq2gX4%3Dreserved=0 > and > carefully reading through the link for "How to get help". Then, you > can post your improved questions in the lighttpd Support Forum, > perhaps with more details about your script. > > When running CGI scripts such as "myscript.pl", lighttpd creates a > standard CGI environment [1], including environment variables such as > QUERY_STRING, so the problem is likely in your Perl script, and likely > a misunderstanding of standard CGI environment variables. > > [1] The Common Gateway Interface (CGI) Version 1.1 > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3875data=04%7C01%7C%7C722d1ee7355143db178608d9845939b8%7C84df9e7fe9f640afb435%7C1%7C0%7C637686341017068026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TBkSGPSbVgIgwjXq7oya4gAKG1ufmm%2F6%2FJgk4bCW3Hc%3Dreserved=0 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Emacs, GnuTLS, and DST Root CA X3
Good news! My problem is solved. > From the ca-certificates-letsencrypt-2.50-3 announcement: > > > It may be necessary to also remove trust for the already expired DST > > X3 root CA > > I'm still trying to figure out _how_ to do this, although I'm not sure > whether it should help my situation. I'll report back with the result. This did the trick. Regarding the outdated version of GnuTLS available in Cygwin, I see that these trust anchor changes constitute a workaround. Furthermore, I see that ca-certificates-2.50-4 and ca-certificates-letsencrypt-2.50-4 were released, which automate the above quoted process. Very nice! My final question would be if ca-certificates-letsencrypt will eventually be merged into ca-certificates? I am now happily browsing the web again in Cygwin Emacs. Thank you to this mailing list and those in IRC who helped me debug the problem. I learned a lot about certificate trust chains in the process! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Question about 'provides' and emacs packaging
On 10/6/2021 4:22 PM, Jon Turney wrote: On 06/10/2021 17:23, Jon Turney wrote: On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) Thinking about this some more, that's probably not how it wants to work, since just installing emacs-common would then require user interaction to solve the problem, rather than just installing emacs-nox as well... Agreed. (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) So all that's left is to fix that. This is discussed somewhat in [1], and it seems that having emacs-common suggest: or weak-dep: on emacs-nox would cause that to be the preferred provide:r by the solver (in the absence of other provide:ing packages being selected or installed) Yes, that sounds right... So I guess we'd need to add something like that to setup.ini and feed that data into the solver as well. ...but I'm not sure it's worth the trouble unless other package maintainers would also have a use for this. As far as emacs is concerned, I'm fine just changing "emacs-nox" to "emacs-basic" so that it's alphabetically first. Ken
Re: Question about 'provides' and emacs packaging
On 06/10/2021 17:23, Jon Turney wrote: On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) Thinking about this some more, that's probably not how it wants to work, since just installing emacs-common would then require user interaction to solve the problem, rather than just installing emacs-nox as well... (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) So all that's left is to fix that. This is discussed somewhat in [1], and it seems that having emacs-common suggest: or weak-dep: on emacs-nox would cause that to be the preferred provide:r by the solver (in the absence of other provide:ing packages being selected or installed) So I guess we'd need to add something like that to setup.ini and feed that data into the solver as well. [1] https://github.com/openSUSE/libsolv/issues/66
[ANNOUNCEMENT] Updated: ca-certificates-2.50-4
The following packages have been uploaded to the Cygwin distribution: * ca-certificates-2.50-4 * ca-certificates-letsencrypt-2.50-4 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This update adds the ca-certificates-letsencrypt package, which when installed will make the ISRG R3 intermediate CA a trust anchor and removes trust for the already expired DST X3 root CA (this should strictly not be necessary, but works around bugs present in some libraries in how alternate chains are constructed and verified). This will allow to successfully verify certificates using the Letsencrypt legacy cert chain in certain applications. Install this package when you currently have trouble accessing sites (due to validation complaining about an expired certificate) that had no problems until about September 30 or October 1 2021 depending on your timezone. Please report to the main Cygwin mailing list if you know of an example that still doesn't work for you (with details for reproducing the validation or application error). -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: ca-certificates-2.50-4
The following packages have been uploaded to the Cygwin distribution: * ca-certificates-2.50-4 * ca-certificates-letsencrypt-2.50-4 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This update adds the ca-certificates-letsencrypt package, which when installed will make the ISRG R3 intermediate CA a trust anchor and removes trust for the already expired DST X3 root CA (this should strictly not be necessary, but works around bugs present in some libraries in how alternate chains are constructed and verified). This will allow to successfully verify certificates using the Letsencrypt legacy cert chain in certain applications. Install this package when you currently have trouble accessing sites (due to validation complaining about an expired certificate) that had no problems until about September 30 or October 1 2021 depending on your timezone. Please report to the main Cygwin mailing list if you know of an example that still doesn't work for you (with details for reproducing the validation or application error). -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: Question about 'provides' and emacs packaging
On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: On 10/5/2021 2:24 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? I don't think we have the transaction capability that would be necessary to specify that the meaning of an already existing package name (two, actually) changes in this manner. You might have to use new package names and place the appropriate obsoletions w.r.t. old names instead. My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. I have no idea if multiple packages can provide the same feature. It's worth trying if it does what you want (you must pick at least one of those). This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) I've only tested setup so far, not calm. Jon, if you're reading this, does calm allow 'requires' and 'provides' to contain arbitrary names that are not package names? Yes.
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/6/2021 11:38 AM, Ken Brown via Cygwin wrote: On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote: The test release of GNU Emacs 28.0.50 crashed on me when using emacs-w32. I can repeat this every time. I attached the trace and stackdump. Windows 11 Pro 64-bit Take Command 27.01.24 x64 Opened a text file using emacs-w32 Ctrl-X Ctrl-C to exit Exit Emacs I did not make any changes to the text file Could this be the following problem that I mentioned in the release announcement? Compilation is done asynchronously, with a log in a buffer called *Async-native-compile-log*. If you run emacs-w32 and exit while a compilation is in progress, you might see a dialog box saying that emacs has aborted and asking if you want to attach a debugger. Just say No. If this annoys you, check the compilation buffer before exiting, and wait for the "Compilation finished" message. I'll add one more thing that I didn't know when I wrote that: You can customize the variable native-comp-async-query-on-exit if you want to be warned that there are compilations in process when you exit. Having said that, I'll still try to track down the cause of the crash. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote: The test release of GNU Emacs 28.0.50 crashed on me when using emacs-w32. I can repeat this every time. I attached the trace and stackdump. Windows 11 Pro 64-bit Take Command 27.01.24 x64 Opened a text file using emacs-w32 Ctrl-X Ctrl-C to exit Exit Emacs I did not make any changes to the text file Could this be the following problem that I mentioned in the release announcement? Compilation is done asynchronously, with a log in a buffer called *Async-native-compile-log*. If you run emacs-w32 and exit while a compilation is in progress, you might see a dialog box saying that emacs has aborted and asking if you want to attach a debugger. Just say No. If this annoys you, check the compilation buffer before exiting, and wait for the "Compilation finished" message. I'll add one more thing that I didn't know when I wrote that: You can customize the variable native-comp-async-query-on-exit if you want to be warned that there are compilations in process when you exit. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GNU Emacs 28.0.50 crash (emacs-w32)
> The test release of GNU Emacs 28.0.50 crashed on me when using > emacs-w32. I can repeat this every time. I attached the trace and > stackdump. Emacs in an X window with this same file did NOT crash. It seems to be something particular to emacs-w32 or a non-X environment. -- Jim Reisert AD1C, , https://www.ad1c.us -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
GNU Emacs 28.0.50 crash (emacs-w32)
The test release of GNU Emacs 28.0.50 crashed on me when using emacs-w32. I can repeat this every time. I attached the trace and stackdump. Windows 11 Pro 64-bit Take Command 27.01.24 x64 Opened a text file using emacs-w32 Ctrl-X Ctrl-C to exit Exit Emacs I did not make any changes to the text file -- Jim Reisert AD1C, , https://www.ad1c.us Backtrace: 0x100608b80 0x1005fe058 0x1004bf5ea 0x1006001ca 0x10060029b 0x100602776 0x10060278a 0x1800640dd 0x18018f508 0x8020f6600 Backtrace: 0x100608b80 0x1005fe058 0x1004bf5ea 0x1006001ca 0x10060029b 0x100602776 0x10060278a 0x1800640dd 0x18018f508 0x10060a258 Backtrace: 0x100608b80 0x1005fe058 0x1004bf5ea 0x1006001ca 0x10060029b 0x100602776 0x10060278a 0x1800640dd 0x18018f508 0x10060a258 emacs-w32.exe.stackdump Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Emacs, GnuTLS, and DST Root CA X3
I followed the recent announcements, but unfortunately the problem persists. I tested on two computers, with the following ca-certificates versions: - ca-certificates-2.40-1 - ca-certificates-2.50-1 - ca-certificates-2.50-2 - ca-certificates-2.50-3 - ca-certificates-2.50-3 AND ca-certificates-letsencrypt-2.50-3 In all cases, the result was the same. >From the ca-certificates-letsencrypt-2.50-3 announcement: > It may be necessary to also remove trust for the already expired DST > X3 root CA I'm still trying to figure out _how_ to do this, although I'm not sure whether it should help my situation. I'll report back with the result. Some (non-Cygwin) Emacs users reported that GnuTLS >= 3.6.14 works. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Question about 'provides' and emacs packaging
Ken Brown via Cygwin-apps writes: > I've only tested setup so far, not calm. Jon, if you're reading this, > does calm allow 'requires' and 'provides' to contain arbitrary names > that are not package names? Yes, Perl is using that to ensure that the distribution packages get updated according to the Perl version, Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Question about 'provides' and emacs packaging
On 10/5/2021 2:24 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? I don't think we have the transaction capability that would be necessary to specify that the meaning of an already existing package name (two, actually) changes in this manner. You might have to use new package names and place the appropriate obsoletions w.r.t. old names instead. My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. I have no idea if multiple packages can provide the same feature. It's worth trying if it does what you want (you must pick at least one of those). This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. I've only tested setup so far, not calm. Jon, if you're reading this, does calm allow 'requires' and 'provides' to contain arbitrary names that are not package names? Ken
Prompt wrapping lines problems
Hello,I have the problem described in this page :https://superuser.com/questions/283236/cygwin-bash-prompt-is-wrapping-lines-on-the-same-line I've tried everything to solved this but I didn't succeed. I have to reinstall again a previous version of cygwin... So please, for the next version of cygwin, resolved this in the package, because it totally drive me crazy... Thanks a lot and thanks for your great work for the cygwin software. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Emacs, GnuTLS, and DST Root CA X3
On 2021-10-05 02:22, Jib Style via Cygwin wrote: Several days ago, root certificate "DST Root CA X3" expired, breaking TLS for many clients. I believe the lastest version of GnuTLS available on Cygwin (3.6.9, 2 years ago) is impacted. Is anyone able to publish a newer version of this package? This impacts me as I use Cygwin Emacs and can no longer open TLS connections to many hosts for the purposes of web browsing and newsgroups. I believe all other Cygwin Emacs users would be impacted also. Repro steps: 1. Install Cygwin default packages. 2. Install Cygwin package emacs-w32 27.2-1. 3. In Cygwin terminal: emacs -nw -Q 4. In Emacs: M-: (url-retrieve-synchronously "https://gnu.org;) Expected: Emacs should load webpage and return a buffer. Actual: Emacs network security manager says certificate expired/could not be verified. After discussing this in the #emacs Libera.chat IRC, the consensus was that the old GnuTLS version is to blame, and that a newer version would fix the problem. Does anyone have similar issues or tips on how to resolve? Thank you. The latest ca-certificates package from Mozilla has been announced as re-released three times recently to attempt to address all the issues. Please read the latest mailing list announcement: [ANNOUNCEMENT] Updated: ca-certificates-2.50-3 https://cygwin.com/pipermail/cygwin/2021-October/249569.html -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
