src/lib/libfetch/common.c, branch releng/12.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F12.02018-09-19T07:04:15ZMake libfetch buildable.2018-09-19T07:04:15ZJung-uk Kimjkim@FreeBSD.org2018-09-19T07:04:15Zurn:sha1:3fd49fe2d4843ceaa8c9b3bc4c77bafe1a0e5091Fix an inverted conditional in the netrc code, which would ignore the2018-05-29T13:07:36ZDag-Erling Smørgravdes@FreeBSD.org2018-05-29T13:07:36Zurn:sha1:5f04ebd4d3ed2b5970913c8b02b2b251a897a3c0
value of $HOME and always use the home directory from the passwd
database, unless $HOME was unset, in which case it would use (null).
While there, clean up handling of netrcfd and add debugging aids.
MFC after: 3 weeks
Use __VA_ARGS__ to simplify the DEBUG macro.2018-05-29T10:28:20ZDag-Erling Smørgravdes@FreeBSD.org2018-05-29T10:28:20Zurn:sha1:c5712d6da1ce9006a3147ab7c8be3b326d3dbc71
MFC after: 3 weeks
lib: further adoption of SPDX licensing ID tags.2017-11-26T02:00:33ZPedro F. Giffunipfg@FreeBSD.org2017-11-26T02:00:33Zurn:sha1:5e53a4f90f82c4345f277dd87cc9292f26e04a29
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
In fetch_resolve(), if the port number or service name is included in2017-08-18T18:20:36ZDag-Erling Smørgravdes@FreeBSD.org2017-08-18T18:20:36Zurn:sha1:3954b52f282721e2aa32cdc81ebd81580ab1582b
the host argument (e.g. "www.freebsd.org:443"), the service pointer,
which is supposed to point to the port or service part, instead points
to the separator, causing getaddrinfo() to fail.
Note that I have not been able to trigger this bug with fetch(1), nor
do I believe it is possible, as libfetch always parses the host:port
specification itself. I discovered it when I copied fetch_resolve()
into an unrelated project.
MFC after: 3 days
r308996 broke IP literals by assuming that a colon could only occur as2017-03-17T14:18:52ZDag-Erling Smørgravdes@FreeBSD.org2017-03-17T14:18:52Zurn:sha1:08a49957b3f06926744987207d542efa2631394d
a separator between host and port, and using strchr() to search for it.
Rewrite fetch_resolve() so it handles bracketed literals correctly, and
remove similar code elsewhere to avoid passing unbracketed literals to
fetch_resolve(). Remove #ifdef INET6 so we still parse IP literals
correctly even if we do not have the ability to connect to them.
While there, fix an off-by-one error which caused HTTP 400 errors to be
misinterpreted as redirects.
PR: 217723
MFC after: 1 week
Reported by: bapt, bz, cem, ngie
libfetch: extra bounds checking through reallocarray(3).2017-03-06T15:38:03ZPedro F. Giffunipfg@FreeBSD.org2017-03-06T15:38:03Zurn:sha1:0012b66baf859a5f6177a6a66e1af0b8b7b3d24d
Reviewed by: des
MFC after: 1 week
Properly indent a default: label and avoid crashing when running2017-02-28T18:10:03ZBjoern A. Zeebbz@FreeBSD.org2017-02-28T18:10:03Zurn:sha1:6d9160409317733fd7cf140d8f33fe408e69ee40
under -v but cannot connect due to trying to print an int as %s [1].
Reported by: andrew [1]
MFC after: 3 days
Add a file descriptor in struct url for netrc2017-02-20T00:14:31ZBaptiste Daroussinbapt@FreeBSD.org2017-02-20T00:14:31Zurn:sha1:d8713bf36156f6c6179cc989fc370a7f9a0ca062
When using libfetch in an application that drops privileges when fetching
like pkg(8) then user complain because the application does not read anymore
${HOME}/.netrc. Now a caller can prepare a fd to the said file and manually
assign it to the structure.
It is also a first step to allow to capsicumize libfetch applications
Reviewed by: allanjude, des
Approved by: des
Differential Revision: https://reviews.freebsd.org/D9678
More debugging code I missed in r309051.2016-12-09T16:14:55ZDag-Erling Smørgravdes@FreeBSD.org2016-12-09T16:14:55Zurn:sha1:3af3efd11537c7bf40ed04be9696b9f5ae2011e9
Reported by: jbeich, jkim