Re: [SECURITY] gnutls
On 2017-03-24 14:00, Yaakov Selkowitz wrote: On 2017-03-10 16:01, Yaakov Selkowitz wrote: On 2017-02-22 12:46, Yaakov Selkowitz wrote: On 2016-09-26 14:13, Yaakov Selkowitz wrote: On 2016-09-26 02:00, Yaakov Selkowitz wrote: Dr. Volker, Two security issues have been reported in GnuTLS: https://www.gnutls.org/security.html#GNUTLS-SA-2016-2 https://www.gnutls.org/security.html#GNUTLS-SA-2016-3 At this point, I think the best way to proceed would be to: 1) release 3.3.24 with the patch for the latter, then; 2) update to 3.4.15, which involves an ABI break. nettle is also overdue for an update (it's also blocking an update to filezilla); getting that in after 3.3.24 and prior to 3.4 would be best. Ping? More vulnerabilities have been announced, so we need to revise the above to 3.3.26 and 3.5.9. Ping 2? Ping 3? I have uploaded the latest versions of nettle and gnutls to fix these issues. -- Yaakov
Re: [SECURITY] libidn - locale specific error in test suite
On 2017-03-24 14:00, Yaakov Selkowitz wrote: On 2017-03-10 16:01, Yaakov Selkowitz wrote: On 2017-02-22 12:58, Yaakov Selkowitz wrote: On 2017-01-19 14:42, Yaakov Selkowitz wrote: On 2017-01-03 04:53, Dr. Volker Zell wrote: Just tried packaging libidn-1.33 and found a locale specific error in the test suite (Which was working fine with my latest build). When running under strace I get: Dr. Volker, Since the bug discovered by this test is unrelated to libidn itself, there should be no need to hold back the libidn release therefor. Ping? Ping 2? Ping 3? I have uploaded the latest version of libidn to fix these issues. -- Yaakov
Re: Neko package
> Looks ok to me. I added neko to your package list. Thanks! I will upload the package soon! >> # cygport cannot auto detect these, since the ndll files are not >> # named with .dll. > > > If these really are just .dll by another name, you might want to explore > patching cygport to teach it that (it already has to deal with some other > non-standard extensions for DLLS) > Good idea! I will look into it. Best regards, Andy
Re: [PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)
On 02/05/2017 20:29, Åke Rehnman wrote: One thought though, why not let wininet take care of file:// URL's as well? Or actually don't try to parse the url string at all and just pass it down to NETIO_IE5 unfiltered? The advantage is setup would be able to I'd be happy to look at a separate patch to do this. See proposed incremental patch. Have a look, give me your thoughts. handle what ever protocols wininet has. Also letting wininet taking care of file:// url's would let the user install from a local network I'm pretty sure I've done that in the past, so I think it already works. The form of file: URL required might not be strictly correct, though, (I think file:server/pathname/ ?) Seem to work with \\server\share_name\path or //server/share_name/path now anyway Thanks for the patch. So there are a few separate things here: * Pass unknown protocols to wininet This seems a fine idea, but isn't what this patch does. * Allow wininet to handle file:// URLs I'm a little bit concerned that there may be current uses which rely on the incorrect parsing we do of file:// URLs to work. Otoh, this should fix the file:// URL format we currently mishandle, so is probably worth doing. * What to do with non-URL (i.e. pathname) addresses? Perhaps WinInet can handle these, but assuming it does, is there a good reason to change from using NetIO_File()? There are also some associated UI issues, in that we give no clue that a pathname is acceptable as a download site, and pathnames and file:// URLs are presented terribly in the download site list.
Re: [PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)
On 03/05/2017 08:22, Brian Inglis wrote: On 2017-05-02 05:05, Jon Turney wrote: On 02/05/2017 08:28, Åke Rehnman wrote: On 2017-05-01 22:45, Jon Turney wrote: I'm pretty sure I've done that in the past, so I think it already works. The form of file: URL required might not be strictly correct, though, (I think file:server/pathname/ ?) I can't see how to get a file:// URL for a local directory to parse correctly, though. URLs are like http://host/path - file://host/path; if no host is given, localhost is assumed in http:///path and file:///path file:/// is the local root but some browsers accept just / e.g. lynx on Cygwin and Linux - useful to test this stuff, as GUI browsers look up URL history for completions. Most Windows browsers require the drive at the start of the path so should accept file:///d|/ (HTML originally allowed ":" only after the proto, and before the password and port in proto://[[[user][:pswd]@]host[:port]]/path so d| was required but that was relaxed in IE, and later other browsers followed), so likely file:///C:/, just C:, maybe C:/, rarely or never /. Yes. Unfortunately, none of this works correctly in setup at the moment. Incorrect URLs of the form 'file:server/pathname/' work in setup, but my attempts to construct something setup would use as a file URL for a local directory were unsuccessful.
Re: Requesting upload privileges
On 03/05/2017 07:13, Joni Eskelinen wrote: Name: Joni Eskelinen Package: cygextreg Done.
Re: [ITP] extractpdfmark 1.0.2
On 30/04/2017 11:31, Masamichi Hosoda wrote: Hi, all Extract PDFmark can extract page mode and named destinations as PDFmark from PDF. By using this you can get the small PDF files that have preserved them. Thanks. extractpdfmark.cygport: DEPEND is for declaring build dependencies. This should include libpoppler-devel runtime dependencies which aren't autodetected should be declared in REQUIRES. ldesc: "Extract PDFmark is able to extract page mode and named destinations as PDFmark from PDF. By using this you can get the small PDF files that have preserved them." The last sentence is a bit unclear to me. What is the referent of the final "them"?.
Re: Neko package
On 30/04/2017 18:51, Andy Li wrote: Let me know if there is any remaining issue. Looks ok to me. I added neko to your package list. # cygport cannot auto detect these, since the ndll files are not # named with .dll. If these really are just .dll by another name, you might want to explore patching cygport to teach it that (it already has to deal with some other non-standard extensions for DLLS)
Re: noarching source packages
On 5/1/2017 4:05 PM, Ken Brown wrote: On 5/1/2017 3:57 PM, Achim Gratz wrote: But the real problem is that besides our own stuff some upstream sources are archful. Examples? Last I looked, it was texlive. This might go back to the time when biber was distributed as a packed perl archive on x86 but not x86_64. No, it was actually due to the existence of source files of the form .-cygwin.tar.xz. But it was fixed a year ago. See the discussion at https://sourceware.org/ml/cygwin-apps/2016-05/msg00049.html and cygport commit 5c559d5ea49d69116d3073b68c8fb1e70522370a. Ken
Re: [PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)
On 2017-05-02 05:05, Jon Turney wrote: > On 02/05/2017 08:28, Åke Rehnman wrote: >> On 2017-05-01 22:45, Jon Turney wrote: > I'm pretty sure I've done that in the past, so I think it already > works. The form of file: URL required might not be strictly correct, > though, (I think file:server/pathname/ ?) > I can't see how to get a file:// URL for a local directory to parse > correctly, though. URLs are like http://host/path - file://host/path; if no host is given, localhost is assumed in http:///path and file:///path file:/// is the local root but some browsers accept just / e.g. lynx on Cygwin and Linux - useful to test this stuff, as GUI browsers look up URL history for completions. Most Windows browsers require the drive at the start of the path so should accept file:///d|/ (HTML originally allowed ":" only after the proto, and before the password and port in proto://[[[user][:pswd]@]host[:port]]/path so d| was required but that was relaxed in IE, and later other browsers followed), so likely file:///C:/, just C:, maybe C:/, rarely or never /. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Requesting upload privileges
Name: Joni Eskelinen Package: cygextreg BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQC7Oubl8eZs+KRHTl+yVtwiR4VBJfdA22sr6z9kxw lkW1yq1QtIcLtD8GDcWCdZ4dTLij4ErGz58I/ppwsAfg4cfFDQInFFyS9o2+cNDSJ/sHN2 orni26TtBVx5YBkapIAFpD98IAtztA7NEuZ+Vl28EfZl5Kys/epFdkRlggN7YXictTkGl/ 1x8eEAi6CH2aJPZWAu9xwnyhBfwdwNaIix8CZB/q/nwBHdHGt+mkv/N40phjvnh32y1FQr hb8Ix1wXipHp+4YVUJMCO5lNQrshbm7eD2vdsQot4fKKHYOxx1AbbG1Z+SLr8XgjMaMtyo /EGgqxXQPneiHogxsySYRr END SSH2 PUBLIC KEY signature.asc Description: OpenPGP digital signature
Re: [ITP] cygregext (formerly cygscript)
On 29.4.2017 14.54, Jon Turney wrote: > On 28/04/2017 21:46, Eric Blake wrote: >> On 04/28/2017 03:08 AM, Joni Eskelinen wrote: >>> Hi all, >> >>> I've renamed cygscript as proposed. Hopefully cygregext conveys its >>> purpose more clearly. A man page has also been added. >> >> My first read was 'cygwin regular-expressions t'. Maybe a slight tweak >> to cygextreg (for cygwin extension registration) keeps the same length >> but with less confusion with an already well-used abbreviation? > > This makes sense to me, but it's your choice. > Thanks for your input. I've renamed the command to cygextreg, hopefully for the last time for now :). TBH i wasn't really happy with the ring of 'regex' in cygregext, so this is definitely better. > Nice work. I'm kind of surprised we don't have something like this > already. >> >> This application is not included in any other distro, so i reckon >> a vote >> must be first passed. > > +1 >> >> At any rate, I'm also +1 for inclusion, whether or not you take my >> naming suggestion. > > Please provide a ssh key as per https://cygwin.com/package-upload.html > I'll proceed with a request.
