All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For
largely historical reasons, ISC also works with those same authors to
publish a canonical list of newsgroups over at ftp.isc.org.
However, as ISC also offers support contracts for BIND and Kea, and those >customers have their own due diligence policies, we are often subject to >scrutiny and audits about how our network runs, and even for a venerable
URL like ftp.isc.org, we get questions from auditors like "did you know
you have a public FTP server on your network! Why!?"
. . .
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
As a benefit, this also allows us to use the CDN provider we already use
for downloads.isc.org. The url would remain ftp.isc.org, and the pathing >would remain the same. We'd still sync the data from Russ as we already
do).
We do not have a specific date yet (this depends on specific feedback from >the community), but on the order of a month or two sounds reasonable. If
any software, such as INN, ships with the "ftp" protocol baked-in, this
gives enough time for people to put out new releases and docs that point
at the change, or at least add the change to their README's, and the like.
If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are welcome.
If there are objections or considerations, please feel free to reply here
or contact me directly.
Hi Wolfgang,<snip>
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even for >>>> a venerable URL like ftp.isc.org, we get questions from auditors like
"did you know you have a public FTP server on your network! Why!?"
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and
outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
You are doing well to remind that. I also regularly see external audits
on some critical systems used for the public transport in Paris where I
work, and we are just asked to follow the recommendations, not to counter-argument them.
For the most vital systems, a certification is needed by the ANSSI in
France. I think it is a bit like the NSA in the USA or the BSI in
Germany.
So I totally understand Dan's position.
Ray Banana <rayban@raybanana.net> wrote:
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and
outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
Fortunately, at a university where I work, there are not so many external >audits. But I believe you that this is a big problem. It would be nice if
ISC offered rsync for selected IP addresses. This would allow us to
continue to operate mirrors that can then be accessed via FTP and HTTPS.
Heiko
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
Thus spake noel <deletethis@invalid.lan>
[...]
{...]However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even
for a venerable URL like ftp.isc.org, we get questions from auditors
like "did you know you have a public FTP server on your network!
Why!?"
Lot of hogwash, so ISC don't have a spine... I wont go into how comical
the excuses are, others have more than adequately stated how silly they
are.
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
be nice if ISC offered rsync for selected IP addresses. This would allow
us to continue to operate mirrors that can then be accessed via FTP and HTTPS.
Heiko
. . .
As far as INN is concerned, I'll soon provide an updated version of
actsyncd which currently can only synchronize the active file from FTP
and NNTP external sources. I'll add support for HTTP(S).
Julien <iulius@nom-de-mon-site.com.invalid> wrote:
As far as INN is concerned, I'll soon provide an updated version of
actsyncd which currently can only synchronize the active file from FTP
and NNTP external sources. I'll add support for HTTP(S).
Could you please generate full directory listings? That's the most
important thing we would be losing here.
All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For
largely historical reasons, ISC also works with those same authors to
publish a canonical list of newsgroups over at ftp.isc.org.
However, as ISC also offers support contracts for BIND and Kea, and those customers have their own due diligence policies, we are often subject to scrutiny and audits about how our network runs, and even for a venerable
URL like ftp.isc.org, we get questions from auditors like "did you know
you have a public FTP server on your network! Why!?"
FTP is also unencrypted, (ftps really never gained any traction as a url scheme), and in the modern internet, a push for SSL everywhere feels reasonable as well. The days of hosting mirrors of other FTP sites seem
to belong to a bygone era, and I've disabled the generation of old-school files like MIRRORED.BY and ls-lr.gz.
We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.
===
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
As a benefit, this also allows us to use the CDN provider we already use
for downloads.isc.org. The url would remain ftp.isc.org, and the pathing would remain the same. We'd still sync the data from Russ as we already
do).
We do not have a specific date yet (this depends on specific feedback from the community), but on the order of a month or two sounds reasonable. If
any software, such as INN, ships with the "ftp" protocol baked-in, this
gives enough time for people to put out new releases and docs that point
at the change, or at least add the change to their README's, and the like.
If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are welcome.
If there are objections or considerations, please feel free to reply here
or contact me directly.
Regards,
-Dan
[...]
The cypherpunk ideals included users controlling their own cryptography rather than being forced to farm out authentication and confidentiality
to third-party interlopers. The true aims of the HTTPS cabal are obvious.
The HTTPS ecosystem is building a censorship and surveillance jail, not
a digital frontier.
"Adam H. Kerman" <ahk@chinet.com> writes:
Julien <iulius@nom-de-mon-site.com.invalid> wrote:
As far as INN is concerned, I'll soon provide an updated version of >>>actsyncd which currently can only synchronize the active file from FTP >>>and NNTP external sources. I'll add support for HTTP(S).
Could you please generate full directory listings? That's the most >>important thing we would be losing here.
The directory listings are already present so far as I can tell, but some >configuration on the ISC web server is hiding files named README so those >aren't showing up in the directory listing (but you can get the file if
you build the URL manually and know it's there).
On Thu, 26 Sep 2024 22:17:36 +0000misguided client security concerns?
Dan Mahoney <dmahoney@isc.org> wrote:
All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For
largely historical reasons, ISC also works with those same authors to
publish a canonical list of newsgroups over at ftp.isc.org.
Keep being historical. This is Usenet, after all. First if you abandon FTP, how long will it be before we see a similar letter from you abandoning NNTP in favor of Mastodon or some other newfangled, censorship-friendly, rent-seeking protocol because of
and enjoy the advertising-driven modern web with its HTTPS cabal tightening the noose around everything? If the rationale is that FTP is outdated, then the same logic should apply to the Big 8 and all of Usenet, the C programming language, the Perl
However, as ISC also offers support contracts for BIND and Kea, and those
customers have their own due diligence policies, we are often subject to
scrutiny and audits about how our network runs, and even for a venerable
URL like ftp.isc.org, we get questions from auditors like "did you know
you have a public FTP server on your network! Why!?"
It's not your fault they don't understand how FTP works. And I am skeptical of this explanation for reasons I will elaborate below.
FTP is also unencrypted, (ftps really never gained any traction as a url
scheme), and in the modern internet, a push for SSL everywhere feels
reasonable as well. The days of hosting mirrors of other FTP sites seem
to belong to a bygone era, and I've disabled the generation of old-school
files like MIRRORED.BY and ls-lr.gz.
It doesn't need to be a bygone era. You could make the same argument for NNTP and Usenet. You might as well just pull the plug now and abolish the Big 8. The Big 8 and Usenet are from the bygone era FTP hails from, so why not just drop it all at once
amputating a hand or foot from the ecosystem.
We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.
This is comparing apples and oranges. Curl and wget don't facilitate directory browsing and FTP/SFTP uploading, downloading, and batch commands in the simple and interactive way facilitated by FTP.
===
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
Simple, it may be. But is it necessary or optimal? That depends on where the censorship goblins embed their controls and peddle pullers in the HTTPS ecosystem. Because that _is_ a thing right now.
As a benefit, this also allows us to use the CDN provider we already use
for downloads.isc.org. The url would remain ftp.isc.org, and the pathing
would remain the same. We'd still sync the data from Russ as we already
do).
Better yet, why not demand the CDN support unauthenticated FTP? It would probably take one of their programmers about three hours to have a working alpha implementation.
We do not have a specific date yet (this depends on specific feedback from >> the community), but on the order of a month or two sounds reasonable. If
any software, such as INN, ships with the "ftp" protocol baked-in, this
gives enough time for people to put out new releases and docs that point
at the change, or at least add the change to their README's, and the like.
Perhaps you might be referring to 'simpleftp' or 'actsync' used with INN? This speaks to my point above about outdating being ubiquitious rather than selective. FTP is part of NNTP management and this has been so for decades. Slicing out FTP is like
also a security risk.
If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are welcome. >>
If there are objections or considerations, please feel free to reply here
or contact me directly.
You could proxy the HTTPS site to a external FTP server that just translates the requests. This would move the FTP target off your network. Anyone trying to call it a security risk would be admitting that every browser connection to your HTTPS site is
actually simpler and leaves both sysop and client in control of their mutual interactions. Cryptography and authentication then occurs on a per-object basis rather than a per-connection basis. The 3rd party certificate authority in the middle _is_ the
Regards,
-Dan
I have more thoughts on why FTP is actually not outdated but is actually being underrated in favor of centralized control schemes that are highly overrated and present massive attack surfaces and censorship mechanisms (looking at you, HTTPS cabal).
One can serve digitally signed and even encrypted files via ftp, removing the need for SSL and certificate authorities. Encryption can be handled on user, event, and file basis rather than connection streams negotiated with certificate lookups. It is
The push for SSL, TLS, and HTTPS on everything is a push to give certificate authorities defacto control over accessibility to all networked hosts, including a centralized veto. I dont't trust the rationales given for this. Had people understood thepower being ceded to these scheming Poindexters and their pocket-protector clout companies, they likely would have called for heads and pounds of flesh.
It looks like the censorship infrastructure is being pushed via centralized control of cryptography, specifically signatures and authentication.Whoever then registers and verifies the keys then has the power to grant or deny access. Extapolate that to the larger Internet for comparison.
Step 1: Force everyone to use SSL.
- Require certificate authorities.
- Require browser pre-configuration.
- Require exploitable attack surface in server and browser handshakes.
Result: defacto 3rd party power to blacklist resources or insert backdoors.
Step 2: Force everyone to use 2FA and passkeys.
- Your SMS number is blacklisted, you can't connect.
- Your SMS number is linked to a bad social credit score and so you are punished.
- Your passkeys are identifiable and revokable by 3rd parties.
Result: defacto blacklisting ability of user authentication.
Step 3: Require active monitoring of dissidents based upon installed or registered certificates and passkeys.
- Down-chain subkey signing can be used to insert cipher keys that allow transparent MITM proxying.
- The government or corporations can then substitute man-in-the middle certificates for selected connections.
- The government or corporations can then block individual connections and authentication.
- The user is completely oblivious if being monitored.
- The user is completely helpless without remedy if being censored or blocked.
Use the The Onion Network as a syllogism for this. It would not be much work to alter the TOR protocol from a mixnet to a key-based authentication network. Currently TOR is open. With subtle changes, it can be converted to a access control ecosystem.
If the files on a FTP server are digitally signed with the downloader verifying signatures then the connection is technically secure even if plaintext. None of these hazards presented by certificate authorities exist in the simpler scheme of per-objectcryptography. The government would need to cut the pipe at the ISP and the affected parties would know immediately and have recourse. Certificate schemes offer sneakier ways to fiddle around with these liberties.
Moreover, authenticated FTP can present unique cipher keys for encryption and decryption based on user and server preferences, and plug in any algorithm desired or allowed by the mutual parties. It's not really outdated. It is just under-used,underrated, and not fully explored in its potential.
In other words, the only substantial thing SSL / TLS / HTTPS do that FTP doesn't do is farm out control over user cryptography to 3rd parties. Thus the security protocol can be remotely transformed into the censorship protocol with the flip of a switchor click of a mouse. Many a hacker working on the source code would unflinchingly accept a bribe to insert a back door bug. Any government can secretly mandate insertion of backdoor bugs or MITM keys with gag orders. What is being done with 'security' is
Don't bore me with lame arguments that the bean counters don't realize this is the infrustructure being layered over the data. That is what it is. It is centralized, fragile, exploitable and unnecessary. The pocket-protector praetorians are solvingevery problem we didn't know we had, making things vastly more complex and exploitable in the process. At least all this complexity boondoggle keeps racking up the billable hours, right?
Simpler schemes would have been more fitting while allowing control to remain exclusively between the negotiating parties. If it were up to me I would let the banks and online shoppers use their certificate authorities, and let everyone else alone withbetter alternatives instead of trying to shoehorn the whole world into a Chinese finger puzzle buried in a jello mold. This way the CA only has power to try censoring those with deep pockets, who would then get into the CA pockets to teach them a lesson.
Theoretically, dropping FTP would allow CAs to shut down or inconvenience a Usenet peer. Although not likely now, circumstances and motives have a way of changing quickly so that less likely becomes actuality.censorship and surveillance jail, not a digital frontier.
The cypherpunk ideals included users controlling their own cryptography rather than being forced to farm out authentication and confidentiality to third-party interlopers. The true aims of the HTTPS cabal are obvious. The HTTPS ecosystem is building a
--
......................................................................... >Timothy C. May | Crypto Anarchy: encryption, digital money, >tcmay@netcom.com | anonymous networks, digital pseudonyms, zero >408-688-5409 | knowledge, reputations, information markets, >W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.
Dan Mahoney <dmahoney@isc.org> wrote:
All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For >>largely historical reasons, ISC also works with those same authors to >>publish a canonical list of newsgroups over at ftp.isc.org.
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even for
a venerable URL like ftp.isc.org, we get questions from auditors like
"did you know you have a public FTP server on your network! Why!?"
It saddens me that people who should know better think that the mere existence of the FTP server potentially compromises security on other
hosts in the network.
I'm sorry you were pressured here.
. . .
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
As a benefit, this also allows us to use the CDN provider we already use >>for downloads.isc.org. The url would remain ftp.isc.org, and the
pathing would remain the same. We'd still sync the data from Russ as we >>already do).
Switching to https is not so simple. Those of us who use it regularly
want to see directory listings. I get these automatically using an ftp
client but not when I use a browser. With a browser, subdirectories are listed but Russ's README is not (I think there are three of them).
Every single directory, then, requires a frequently regenerated
index.html file that's literally a directory listing, both files and subdirectories.
With a browser, subdirectories are
listed but Russ's README is not (I think there are three of them).
However, some files may be named in such a way that they aren't
being picked up by the directory indexing code. That could be
rectified, and I hope they do so.
Hi Adam, vallor,
With a browser, subdirectories are
listed but Russ's README is not (I think there are three of them).
However, some files may be named in such a way that they aren't
being picked up by the directory indexing code. That could be
rectified, and I hope they do so.
Seems like you have been heard :)
<https://ftp.isc.org/pub/pgpcontrol/> and ><https://ftp.isc.org/usenet/CONFIG/> for instance look good to me, with
the README file listed.
Hi Adam, vallor,
With a browser, subdirectories are listed but Russ's README is not (I
think there are three of them).
However, some files may be named in such a way that they aren't being
picked up by the directory indexing code. That could be rectified, and
I hope they do so.
Seems like you have been heard :) <https://ftp.isc.org/pub/pgpcontrol/>
and <https://ftp.isc.org/usenet/CONFIG/> for instance look good to me,
with the README file listed.
If any software, such as INN, ships with the "ftp"
protocol baked-in, this gives enough time for people to put out new
releases and docs that point at the change, or at least add the
change to their README's, and the like.
Might be true, but be aware that most systems run on operating systems
that don't always have the latest upstream packages. Systems like
Debian have package versions that are sometimes older than 1 or 2 years
with security backports.
If there are objections or considerations, please feel free to reply
here or contact me directly.
I don't see a real reason to shut down the ftp server. If some of your customers don't like the FTP protocol, they don't need to use it.
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even
for a venerable URL
like ftp.isc.org, we get questions from auditors like "did you know
you have a public FTP server on your network! Why!?"
We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to
HTTPS. As a benefit, this also allows us to use the CDN provider we
already use for downloads.isc.org.
We do not have a specific date yet (this depends on specific feedback
from the community), but on the order of a month or two sounds
reasonable.
If any software, such as INN, ships with the "ftp"
protocol baked-in, this gives enough time for people to put out new
releases and docs that point at the change, or at least add the
change to their README's, and the like.
If there are objections or considerations, please feel free to reply
here or contact me directly.
Dan Mahoney <dmahoney@isc.org> wrote:
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
As a benefit, this also allows us to use the CDN provider we already use >>for downloads.isc.org. The url would remain ftp.isc.org, and the pathing >>would remain the same. We'd still sync the data from Russ as we already >>do).
Switching to https is not so simple. Those of us who use it regularly
want to see directory listings. I get these automatically using an ftp
client but not when I use a browser. With a browser, subdirectories are listed but Russ's README is not (I think there are three of them).
Every single directory, then, requires a frequently regenerated
index.html file that's literally a directory listing, both files and subdirectories.
["Followup-To:" header set to news.software.nntp.]
On Thu, 26 Sep 2024 22:56:19 -0000 (UTC), Adam H. Kerman wrote:
Dan Mahoney <dmahoney@isc.org> wrote:
Ergo, it seems to be a simple enough matter to tell people who fetch >>>those usenet control files via anonymous FTP to simply switch to HTTPS. >>>As a benefit, this also allows us to use the CDN provider we already use >>>for downloads.isc.org. The url would remain ftp.isc.org, and the pathing >>>would remain the same. We'd still sync the data from Russ as we already >>>do).
Switching to https is not so simple. Those of us who use it regularly
want to see directory listings. I get these automatically using an ftp >>client but not when I use a browser. With a browser, subdirectories are >>listed but Russ's README is not (I think there are three of them).
Every single directory, then, requires a frequently regenerated
index.html file that's literally a directory listing, both files and >>subdirectories.
I've been running HTTP/HTTPS servers for several decades now, including >really obscure ones embedded on microcontrollers and I can't think of a >single one -- much less one you would consider using today that doesn't
have a built-in facility to dynamically generate a directory listing at
the time of requeste. One does not need to (re-)generate index.html
files, the server will synthetically do that if configured properly.
I certainly will be sad to see FTP go away, but this is unlikely to
be a persuasive argument to anyone configuring or maintaining the
HTTP/HTTPS server.
The days of hosting mirrors of other FTP sites seem to belong to a bygone era, [...]
All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For
largely historical reasons, ISC also works with those same authors to
publish a canonical list of newsgroups over at ftp.isc.org.
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even for
a venerable URL like ftp.isc.org, we get questions from auditors like
"did you know you have a public FTP server on your network! Why!?"
FTP is also unencrypted, (ftps really never gained any traction as a url scheme), and in the modern internet, a push for SSL everywhere feels reasonable as well. The days of hosting mirrors of other FTP sites seem
to belong to a bygone era, and I've disabled the generation of
old-school files like MIRRORED.BY and ls-lr.gz.
We also no longer live in the world where a copy of curl/wget that
supports modern ciphers is not available everywhere.
===
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to HTTPS.
As a benefit, this also allows us to use the CDN provider we already use
for downloads.isc.org. The url would remain ftp.isc.org, and the
pathing would remain the same. We'd still sync the data from Russ as we already do).
We do not have a specific date yet (this depends on specific feedback
from the community), but on the order of a month or two sounds
reasonable. If any software, such as INN, ships with the "ftp" protocol baked-in, this gives enough time for people to put out new releases and
docs that point at the change, or at least add the change to their
README's, and the like.
If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are
welcome.
If there are objections or considerations, please feel free to reply
here or contact me directly.
Regards,
-Dan
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even for
a venerable URL like ftp.isc.org, we get questions from auditors like
"did you know you have a public FTP server on your network! Why!?"
I've been working for several large companies that are legally required
to carry out annual audits of their IT infrastucture, both internal and outsourced, and had to deal with external auditors from PWC, KPMG and
E&Y, to name just a few, and I know that it's absolutely impossible to
argue with external auditors and your customers' management if you care
about your mental health. They will drag you down to their level and
beat you with experience, so ISC is not to blame, IMHO.
{...]However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even for
a venerable URL like ftp.isc.org, we get questions from auditors like
"did you know you have a public FTP server on your network! Why!?"
Lot of hogwash, so ISC don't have a spine... I wont go into how comical
the excuses are, others have more than adequately stated how silly they
are.
If/when this happens I'd likely also make a quick post to a few other
network operator places, and suggestions as to where to do so are welcome.
We do not have a specific date yet (this depends on specificAs for INN, I have just done the work, and updated the actsyncd and
feedback from the community), but on the order of a month or two
sounds reasonable. If any software, such as INN, ships with the
"ftp" protocol baked-in, this gives enough time for people to put
out new releases and docs that point at the change, or at least add
the change to their README's, and the like.
Maybe <https://www.big-8.org/> to start with? I see references to <ftp://ftp.isc.org/> when searching in their web site.
B/ If actsyncd is used with the following actsync.cfg parameters:
host=ftp.isc.org
ftppath=/pub/usenet/CONFIG/active.gz
Then there is something to change. Here are some possibilities.
1/ The fastest would be to keep FTP but against another server which
would go on providing up to date active files on FTP. I don't know
whether there are. If you know one, just update host and ftppath accordingly.
2/ You can install a version of INN generated after 2024-10-07 (INN
2.7.3, snapshot, etc.). Then just update your installation and change
the above parameters in actsync.cfg to:
host=downloads.isc.org
path=/pub/usenet/CONFIG/active.gz
protocol=https
Dan Mahoney <dmahoney@isc.org> wrote:
All,
ISC is the operator of the F-root DNS server as well as the makers of
BIND, ISC DHCP, Kea, as well as historic other pieces of software. We
also have had a long relationship with the team that makes INN. For >>largely historical reasons, ISC also works with those same authors to >>publish a canonical list of newsgroups over at ftp.isc.org.
However, as ISC also offers support contracts for BIND and Kea, and
those customers have their own due diligence policies, we are often
subject to scrutiny and audits about how our network runs, and even
for a venerable URL like ftp.isc.org, we get questions from auditors
like "did you know you have a public FTP server on your network!
Why!?"
It saddens me that people who should know better think that the mere existence of the FTP server potentially compromises security on other
hosts in the network.
I'm sorry you were pressured here.
. . .
Ergo, it seems to be a simple enough matter to tell people who fetch
those usenet control files via anonymous FTP to simply switch to
HTTPS. As a benefit, this also allows us to use the CDN provider we >>already use for downloads.isc.org. The url would remain ftp.isc.org,
and the pathing would remain the same. We'd still sync the data from
Russ as we already do).
Switching to https is not so simple. Those of us who use it regularly
want to see directory listings. I get these automatically using an ftp
client but not when I use a browser. With a browser, subdirectories
are listed but Russ's README is not (I think there are three of them).
Every single directory, then, requires a frequently regenerated
index.html file that's literally a directory listing, both files and subdirectories.
We do not have a specific date yet (this depends on specific feedback
from the community), but on the order of a month or two sounds
reasonable. If any software, such as INN, ships with the "ftp"
protocol baked-in, this gives enough time for people to put out new >>releases and docs that point at the change, or at least add the change
to their README's, and the like.
If/when this happens I'd likely also make a quick post to a few other >>network operator places, and suggestions as to where to do so are
welcome.
If there are objections or considerations, please feel free to reply
here or contact me directly.
I don't think there is a problem to solve, but it's too late for the
pebbles to vote. I sort of expected this to happen years ago.
Hi all,
In addition to my previous message:
B/ If actsyncd is used with the following actsync.cfg parameters:
host=ftp.isc.org
ftppath=/pub/usenet/CONFIG/active.gz
Then there is something to change. Here are some possibilities.
1/ The fastest would be to keep FTP but against another server which
would go on providing up to date active files on FTP. I don't know
whether there are. If you know one, just update host and ftppath
accordingly.
The good news is that the Free University of Berlin still has an FTP
server, and they now get the newsgroups information from the same source
as ftp.isc.org takes theirs (that is to say control-archive maintained
by Russ). So, if and when ftp.isc.org closes as an FTP server, changing actsync.cfg to:
host=ftp.fu-berlin.de
ftppath=/doc/usenet/config/active.gz
will go on synchronizing the data using the FTP protocol.
Thanks, Heiko and Russ!
2/ You can install a version of INN generated after 2024-10-07 (INN
2.7.3, snapshot, etc.). Then just update your installation and change
the above parameters in actsync.cfg to:
host=downloads.isc.org
path=/pub/usenet/CONFIG/active.gz
protocol=https
Switching to HTTPS is also still possible of course.
Note that we don't know how much time the FTP protocol will remain
active in the server of the Free University of Berlin. There's no
lifetime guarantee.
At least actsyncd can now deal with both FTP and HTTPS so it will be
ready in case FTP is also shut down on other servers. By the time it happens, I hope the new version will be wide-spread.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:23:51 |
| Calls: | 10,388 |
| Calls today: | 3 |
| Files: | 14,061 |
| Messages: | 6,416,843 |
| Posted today: | 1 |