RubenKelevra / pacman.store

Pacman Mirror via IPFS for ArchLinux, Endeavouros, Manjaro plus custom repos ALHP and Chaotic-AUR.
GNU General Public License v3.0
109 stars 5 forks source link

IPFS-Companion is creating non-working URLs for this repo #28

Open rpodgorny opened 4 years ago

rpodgorny commented 4 years ago

what i just experienced:

1) browsed the files of your ipfs arch repo at http://x86-64.archlinux.pkg.pacman.store.ipns.localhost:8080/iso/latest (local gateway with local ipfs node) 2) clicked "copy shareable link" at the ipfs companion firefox extension 3) pasted the url to address bar in another tab: https://x86-64.archlinux.pkg.pacman.store.ipns.dweb.link/iso/latest 4) i ended up with ssl certificate error:

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for x86-64.archlinux.pkg.pacman.store.ipns.dweb.link. The certificate is only valid for the following names: *.i.ipfs.io, *.ipfs.dweb.link, *.ipfs.io, *.ipns.dweb.link, dweb.link, ipfs.io

Error code: SSL_ERROR_BAD_CERT_DOMAIN

...so i guess the "*" wildcard character only covers a single-level subdomain, not "infinite"-level.

migrating to something like "x86-64-archlinux-pkg-pacman-store.ipns.dweb.link" would probably solve the issue but i can imagine it's not feasible for some reason i'm not aware of. :-(

...so, what to do now?

teknomunk commented 3 years ago

I believe this issue is not specific to this project, but an issue with IPFS, the dweb.link webserver and/or the IPFS companion, and maybe with subdomain-certificate handling in the web browser you use.

As you note, the subdomain is causing a certificate error. I tried navigating to https://dweb.link/ipns/x86_64.archlinux.pkg.pqcman.store/iso/latest/, and was promptly redirected to the subdomain that you report as not working. This redirect is being done by the webserver sitting at dweb.link (and is either the ipfs daemon itself or the daemon with a reverse proxy in front of it).

The subdomain redirect was recently added to IPFS. The companion is likely taking this into account (I don't have the companion installed, so I can't check it myself).

My suggestion is to make a bug report at the IPFS project, as this is probably the result of the subdomain redirect and is there responsibility to fix. This issue looks like our affects more sites than just pacman.store.

If you do, please add a link to the issue here so that we can track it.

mohe2015 commented 3 years ago

Web browsers don't support multi level wildcard certificates so this should probably be changed.

RubenKelevra commented 3 years ago

@rpodgorny

I'm open to suggestions and I can confirm this issue, but I don't think a non-dotted domain name would change anything.

Please report this issue upstream, as I don't think I can do anything to fix this. Additionally my bug about the non-working redirect is still open and escalated to go-ipfs, see - this might be related.

https://github.com/ipfs-shipyard/ipfs-companion/issues/877 https://github.com/ipfs/go-ipfs/issues/7439

@mohe2015 wrote:

Web browsers don't support multi level wildcard certificates so this should probably be changed.

Right, so https://store.ipns.dweb.link works fine. But I currently have not enough money on my bank account to get TLD. :)

mohe2015 commented 3 years ago

@RubenKelevra I'm sorry, I didn't read properly.

rpodgorny commented 3 years ago

agreed, this is more fundamental problem of ipfs (and/or ipfs-companion) itself.

i've subscribed to the mentioned bug reports and will follow the progress there. feel free to close this one. thanks.

RubenKelevra commented 3 years ago

@rpodgorny Your welcome!

Will close this one as soon as the issue is fixed upstream.