this command used to work with domain without `/ipns/` prefix.
we've switched it to the same backend as `resolve` command,
which requires the prefix, so we add it if it is missing
* fix(commands): routing put command returns the IPNS ID rather than the host's ID
* fix(commands): routing put command errors with the allow-offline hint if the error is an offline error
* fix: test expects correct error message
---------
Co-authored-by: Henrique Dias <hacdias@gmail.com>
Fixes#8492
This introduces "nopfs" as a preloaded plugin into Kubo
with support for denylists from https://github.com/ipfs/specs/pull/383
It automatically makes Kubo watch *.deny files found in:
- /etc/ipfs/denylists
- $XDG_CONFIG_HOME/ipfs/denylists
- $IPFS_PATH/denylists
* test: Gateway.NoFetch and GatewayOverLibp2p
adds missing tests for "no fetch" gateways one can expose,
in both cases the offline mode is done by passing custom
blockservice/exchange into path resolver, which means
global path resolver that has nopfs intercept is not used,
and the content blocking does not happen on these gateways.
* fix: use offline path resolvers where appropriate
this fixes the problem described in
https://github.com/ipfs/kubo/pull/10161#issuecomment-1782175955
by adding explicit offline path resolvers that are backed
by offline exchange, and using them in NoFetch gateways
instead of the default online ones
---------
Co-authored-by: Henrique Dias <hacdias@gmail.com>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
This is a Q&D fix to get kubo building again, this is completely equivalent to what we used to have.
I'll submit a patch that DI the verifcid.Allowlist interface with fx later but this is needed to unblock something else.
* feat!: dag import - don't pin roots by default
Fixes: https://github.com/ipfs/kubo/issues/9765
* test(ipip-402): dag import
this adds basic regression test that guards behavior
around partial cars with or without pinning
* docs(ipip-402): ipip and dag import changelog
---------
Co-authored-by: Marcin Rataj <lidel@lidel.org>
* fix: useful errors during dag import
Most of the time the error is either a bitflip in one of blocks,
or a truncation of car stream.
This allows user to understand what happened
and at which place in the car stream, making debug more humane.
* fix: correct message when root pin failed
this also correctly exits CLI commands with code 1 (was silent
false-positive 0 before)
See https://github.com/ipfs/boxo/pull/290
This PR follow the changes in the Pinner to make listing recursive and direct pins asynchronous, which in turns allow pin/ls to build and emit results without having to wait anything, or accumulate too much in memory.
Note: there is a tradeoff for pin/ls?type=all:
- keep the recursive pins in memory (which I chose)
- ask the pinner twice for the recursive pins, and limit memory usage
Also, follow the changes in the GC with similar benefit of not having to wait the full pin list. Add a test.
Also, follow the changes in pin.Verify.
This fixes a deadlock introduced in 1457b4fd4a.
We can't use the coreapi here because it will try to take the PinLock (RLock) again, so revert this small part of 1457b4fd4a.
This used cause a deadlock when concurrently running `ipfs dag import` concurrently with the GC.
The bug is that `ipfs dag import` takes an RLock with the PinLock.
*the cars are imported, leaving a wide window of time*
Then GC Takes a Lock on that same RWMutex while taking the GC Lock (it blocks because it waits for the RLock to be released).
Then the car imports are finished and `ipfs dag import` tries to aqcuire the PinLock (doing an RLock) again in `Api().Pin`.
However at this point the RWMutex is starved, the runtime put a fence in front of RLocks if a Lock has been waiting for too lock (else you could have an endless stream of RLock / RUnlock forever delaying a Lock to ever go through).
The issue is that `ipfs dag import`'s original RLock which is blocking everyone will be released once it returns, which only happens when `Api().Pin` completes.
So we have a deadlock (ABA kind ?), because `ipfs dag import` waits on the GC Lock, which waits on `ipfs dag import`.
Calling the Pinner directly does not acquire the PinLock again, and thus does not have this issue.
- don't bypass the CoreApi
- don't use a goroutine and return channel for `importWorker`, when what's happening is really just a synchronous call
- only `PinLock()` when we are going to pin
- use `cid.Set` instead of an explicit map
- fail the request early if any pinning fail, no need to try to pin more if the request failed already
