Very dangerous feature and I'm uncertain how hosting works in practice for others as I've only downloaded from warez bots in recent years. Just designate an entire folder as the available content? Lots of investigation needed, we shouldn't just follow historical prescedent but make a safety method of hosting that the user can trust and can't leak data beyond what we intend to host.
XDCC will require its own section in the settings pane for IRC and UI elements for in progress downloads.
Very dangerous feature and I'm uncertain how hosting works in practice for others as I've only downloaded from warez bots in recent years. Just designate an entire folder as the available content? Lots of investigation needed, we shouldn't just follow historical prescedent but make a safety method of hosting that the user can trust and can't leak data beyond what we intend to host.
XDCC will require its own section in the settings pane for IRC and UI elements for in progress downloads.
On the question in the description — no, not a designated folder. That is mIRC's fserve, which hands the far end a dir/cd/get shell against a root directory, and it is exactly where the historical escapes came from. Real XDCC bots (iroffer, dinoex) serve a numbered pack list and a request names a number, never a path. That is what the offering half will do.
How the receive half is made safe
No string from the network reaches the filesystem. The name written is derived by the daemon and joined onto its own configured directory, so traversal is unrepresentable rather than blocked.
Limits are enforced against the stream, never the claim. A sender that runs past the size it offered is cut off.
The daemon writes the file, so no window can aim a network-driven write.
Naming is Windows-strict everywhere: reserved device names, and the trailing dots and spaces Windows silently drops. downloads.ts had the same job and the same gaps and is now in step.
Nothing listens. Receiving only ever dials out, which is checkable — the only TcpListener in the daemon is in these tests.
Tor — a transfer takes the route of the connection that carried the offer, so a server reached through Tor transfers through Tor and the far end sees the exit. The route is published by the live connection rather than rebuilt from account config, because the two can disagree: turning Tor off in settings does not move a connection already up. Reverse (passive) offers are refused — DCC has no field that could carry an onion address, so publishing one would have to be the real one.
26 tests, including the transfer running against a real socket. Two bugs surfaced while writing them: acknowledging a chunk to a sender that has closed provokes a reset which discards data already received (a lost file), and waiting for the sender to close rather than finishing when the offered bytes have arrived could deadlock.
Still to do here: the offering half — an explicit pack list plus one-off /dcc send, requests answered by number only, paths re-checked at send time. On a Tor account it will be passive-only, since that is the one shape where the offering side still dials out.
Receiving half is in. Offering files is still to come, so this stays open.
Finished (receive): nobilis [1fdc8a5](https://git.salastil.com/Salastil/nobilis/commit/1fdc8a5), moho [3dc89f6](https://git.salastil.com/Salastil/moho/commit/3dc89f6)
**On the question in the description** — no, not a designated folder. That is mIRC's `fserve`, which hands the far end a `dir`/`cd`/`get` shell against a root directory, and it is exactly where the historical escapes came from. Real XDCC bots (iroffer, dinoex) serve a numbered pack list and a request names a *number*, never a path. That is what the offering half will do.
**How the receive half is made safe**
- No string from the network reaches the filesystem. The name written is derived by the daemon and joined onto its own configured directory, so traversal is unrepresentable rather than blocked.
- Limits are enforced against the stream, never the claim. A sender that runs past the size it offered is cut off.
- The daemon writes the file, so no window can aim a network-driven write.
- Naming is Windows-strict everywhere: reserved device names, and the trailing dots and spaces Windows silently drops. `downloads.ts` had the same job and the same gaps and is now in step.
- **Nothing listens.** Receiving only ever dials out, which is checkable — the only `TcpListener` in the daemon is in these tests.
**Tor** — a transfer takes the route of the connection that carried the offer, so a server reached through Tor transfers through Tor and the far end sees the exit. The route is published by the live connection rather than rebuilt from account config, because the two can disagree: turning Tor off in settings does not move a connection already up. Reverse (passive) offers are refused — DCC has no field that could carry an onion address, so publishing one would have to be the real one.
26 tests, including the transfer running against a real socket. Two bugs surfaced while writing them: acknowledging a chunk to a sender that has closed provokes a reset which discards data already received (a lost file), and waiting for the sender to close rather than finishing when the offered bytes have arrived could deadlock.
**Still to do here:** the offering half — an explicit pack list plus one-off `/dcc send`, requests answered by number only, paths re-checked at send time. On a Tor account it will be passive-only, since that is the one shape where the offering side still dials out.
Sending is in, which completes both halves. Offered from a name in the member list or from a message somebody wrote, with the system's own file picker.
Why sending is the half with conditions on it. Receiving only ever dials out. Sending has to listen and publish an address, so it is refused outright on a connection through a proxy — the address it would have to give out is the one the proxy exists to keep quiet. Sending from behind Tor needs the reverse form of DCC, where the receiver listens and we dial; that is a separate thing to build, not a flag to flip.
Which address to publish has no good automatic answer, so: anything set by hand wins, because nothing else can be right behind a router — the machine knows its own side of one and not the side the other person has to reach. Failing that, it is the address this machine would use to reach the IRC server, found by asking the system which route it would take rather than by sending anything. There is a setting for the manual case.
An offer nobody takes gives up after three minutes rather than holding a port open all day. Sending is held to the same speed limit as receiving, for a better reason — an upload at full speed is what makes the rest of a home connection unusable.
Not done, and deliberately: the numbered pack list from the original design. That is the standing-offer half — you would be running an XDCC bot — and nothing so far has needed it. The safety design for it stands as written above: requests answered by number only, paths re-resolved and re-checked at send time. Say the word if it is wanted.
247 tests, including the send driven against a real socket. Both targets cross-build.
Finished: nobilis [10d75ac](https://git.salastil.com/Salastil/nobilis/commit/10d75ac), moho [823dc93](https://git.salastil.com/Salastil/moho/commit/823dc93)
Sending is in, which completes both halves. Offered from a name in the member list or from a message somebody wrote, with the system's own file picker.
**Why sending is the half with conditions on it.** Receiving only ever dials out. Sending has to listen and publish an address, so it is refused outright on a connection through a proxy — the address it would have to give out is the one the proxy exists to keep quiet. Sending from behind Tor needs the reverse form of DCC, where the receiver listens and we dial; that is a separate thing to build, not a flag to flip.
Which address to publish has no good automatic answer, so: anything set by hand wins, because nothing else can be right behind a router — the machine knows its own side of one and not the side the other person has to reach. Failing that, it is the address this machine would use to reach the IRC server, found by asking the system which route it would take rather than by sending anything. There is a setting for the manual case.
An offer nobody takes gives up after three minutes rather than holding a port open all day. Sending is held to the same speed limit as receiving, for a better reason — an upload at full speed is what makes the rest of a home connection unusable.
**Not done, and deliberately:** the numbered pack list from the original design. That is the standing-offer half — you would be running an XDCC bot — and nothing so far has needed it. The safety design for it stands as written above: requests answered by number only, paths re-resolved and re-checked at send time. Say the word if it is wanted.
247 tests, including the send driven against a real socket. Both targets cross-build.
The numbered pack list is dropped, not deferred. Serving a standing catalogue is being an XDCC bot, and that is dedicated software's job - iroffer and its like exist, they do it properly, and a chat client growing a worse version of one would be carrying the most dangerous code here for the smallest reason.
What that leaves is the two things a chat client should do, and both are done:
Sending one file to one person - nobilis 10d75ac, moho 823dc93
Dropping the catalogue also drops the risk the original description was worried about. There is no directory designated as available, nothing browsable, and no request that names anything: a file leaves this machine only because somebody picked it in the system file picker and chose who to send it to. The question the description asked - whether to designate a whole folder - now has no place left to be answered wrongly.
The safety properties that remain are the ones already built: a name from the network never reaches the filesystem, limits run against the stream rather than the claim, receiving only ever dials out, and sending is refused on a proxied connection rather than publishing the address the proxy exists to hide.
Finished.
The numbered pack list is dropped, not deferred. Serving a standing catalogue is being an XDCC bot, and that is dedicated software's job - iroffer and its like exist, they do it properly, and a chat client growing a worse version of one would be carrying the most dangerous code here for the smallest reason.
What that leaves is the two things a chat client should do, and both are done:
- **Receiving** - nobilis [1fdc8a5](https://git.salastil.com/Salastil/nobilis/commit/1fdc8a5), moho [3dc89f6](https://git.salastil.com/Salastil/moho/commit/3dc89f6)
- **Sending one file to one person** - nobilis [10d75ac](https://git.salastil.com/Salastil/nobilis/commit/10d75ac), moho [823dc93](https://git.salastil.com/Salastil/moho/commit/823dc93)
Dropping the catalogue also drops the risk the original description was worried about. There is no directory designated as available, nothing browsable, and no request that names anything: a file leaves this machine only because somebody picked it in the system file picker and chose who to send it to. The question the description asked - whether to designate a whole folder - now has no place left to be answered wrongly.
The safety properties that remain are the ones already built: a name from the network never reaches the filesystem, limits run against the stream rather than the claim, receiving only ever dials out, and sending is refused on a proxied connection rather than publishing the address the proxy exists to hide.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Very dangerous feature and I'm uncertain how hosting works in practice for others as I've only downloaded from warez bots in recent years. Just designate an entire folder as the available content? Lots of investigation needed, we shouldn't just follow historical prescedent but make a safety method of hosting that the user can trust and can't leak data beyond what we intend to host.
XDCC will require its own section in the settings pane for IRC and UI elements for in progress downloads.
Receiving half is in. Offering files is still to come, so this stays open.
Finished (receive): nobilis 1fdc8a5, moho 3dc89f6
On the question in the description — no, not a designated folder. That is mIRC's
fserve, which hands the far end adir/cd/getshell against a root directory, and it is exactly where the historical escapes came from. Real XDCC bots (iroffer, dinoex) serve a numbered pack list and a request names a number, never a path. That is what the offering half will do.How the receive half is made safe
downloads.tshad the same job and the same gaps and is now in step.TcpListenerin the daemon is in these tests.Tor — a transfer takes the route of the connection that carried the offer, so a server reached through Tor transfers through Tor and the far end sees the exit. The route is published by the live connection rather than rebuilt from account config, because the two can disagree: turning Tor off in settings does not move a connection already up. Reverse (passive) offers are refused — DCC has no field that could carry an onion address, so publishing one would have to be the real one.
26 tests, including the transfer running against a real socket. Two bugs surfaced while writing them: acknowledging a chunk to a sender that has closed provokes a reset which discards data already received (a lost file), and waiting for the sender to close rather than finishing when the offered bytes have arrived could deadlock.
Still to do here: the offering half — an explicit pack list plus one-off
/dcc send, requests answered by number only, paths re-checked at send time. On a Tor account it will be passive-only, since that is the one shape where the offering side still dials out.Finished: nobilis 10d75ac, moho 823dc93
Sending is in, which completes both halves. Offered from a name in the member list or from a message somebody wrote, with the system's own file picker.
Why sending is the half with conditions on it. Receiving only ever dials out. Sending has to listen and publish an address, so it is refused outright on a connection through a proxy — the address it would have to give out is the one the proxy exists to keep quiet. Sending from behind Tor needs the reverse form of DCC, where the receiver listens and we dial; that is a separate thing to build, not a flag to flip.
Which address to publish has no good automatic answer, so: anything set by hand wins, because nothing else can be right behind a router — the machine knows its own side of one and not the side the other person has to reach. Failing that, it is the address this machine would use to reach the IRC server, found by asking the system which route it would take rather than by sending anything. There is a setting for the manual case.
An offer nobody takes gives up after three minutes rather than holding a port open all day. Sending is held to the same speed limit as receiving, for a better reason — an upload at full speed is what makes the rest of a home connection unusable.
Not done, and deliberately: the numbered pack list from the original design. That is the standing-offer half — you would be running an XDCC bot — and nothing so far has needed it. The safety design for it stands as written above: requests answered by number only, paths re-resolved and re-checked at send time. Say the word if it is wanted.
247 tests, including the send driven against a real socket. Both targets cross-build.
Finished.
The numbered pack list is dropped, not deferred. Serving a standing catalogue is being an XDCC bot, and that is dedicated software's job - iroffer and its like exist, they do it properly, and a chat client growing a worse version of one would be carrying the most dangerous code here for the smallest reason.
What that leaves is the two things a chat client should do, and both are done:
Dropping the catalogue also drops the risk the original description was worried about. There is no directory designated as available, nothing browsable, and no request that names anything: a file leaves this machine only because somebody picked it in the system file picker and chose who to send it to. The question the description asked - whether to designate a whole folder - now has no place left to be answered wrongly.
The safety properties that remain are the ones already built: a name from the network never reaches the filesystem, limits run against the stream rather than the claim, receiving only ever dials out, and sending is refused on a proxied connection rather than publishing the address the proxy exists to hide.