namecoin / ncdns-nsis Goto Github PK

Right now the only Chromium message being logged when Chromium isn't detected is *** Chromium support was not configured., which doesn't actually tell me that Chromium wasn't detected.

The installer should log when Chromium isn't detected.

(h/t to @samurai321 for providing an install log that demonstrated this issue.)

Latest URL's:

• Meta (useful for our reference but we shouldn't link users to it)
• x86 32-bit
• x86 64-bit
• ARM 64-bit

I would like to relicense this repo from MIT to GPLv3+. If there are any objections, please post in this issue within 1 month.

We should test the following environment:

1. Fresh Windows installation; never had Namecoin on it before. Date/time accurate.
2. Enable CAPI2 in Event Viewer.
3. Launch Edge before launching ncdns installer.
4. Run ncdns-nsis, enable TLS.
5. Without restarting Edge, try to visit a .bit TLS site.

If a cert error appears, inspect the CAPI2 logs to see where the cert chain is failing to verify, and see which AIA URL's were queried.

I suspect that there may be some limits on how many AIA queries can be done for a single cert chain building operation, and that our usage of an intermediate TLD CA and/or our usage of HTTPS AIA URL's may be inflating our contribution toward that limit. Or who knows, maybe it actually does work already.

If the user installs ncdns and selects BitcoinJ instead of Namecoin Core, ncdns is still configured to use cookie authentication. This causes ncdns to fail when making RPC requests, either because the cookie file doesn't exist, or because the directory containing the cookie file doesn't exist (not certain which).

This happened to me on a fresh install of Windows 10 32-bit. It didn't happen on an install of Windows 7 64-bit that had previously had ncdns installed with Namecoin Core selected; I suspect this is because either the cookie directory or the cookie file was still leftover from the Namecoin Core installation on the Windows 7 64-bit system.

Unbound is written in C, which has poor memory safety. We might want to look into a memory-safe replacement, e.g. something written in Go.

Blocked by #124 .
Blocked by #125 .

The top 2 Go results for "recursive dns" on GitHub are:

• https://github.com/tenta-browser/tenta-dns
• https://github.com/rolandshoemaker/solvere

According to https://linux.die.net/man/5/unbound.conf , it's incorrect to have stub-zone: as a subclause of server:; the 2-space indent of stub-zone: and its children should be removed from https://github.com/namecoin/ncdns-nsis/blob/master/ncdns-inst.conf.in .

When the user cancels the Namecoin Core or DnssecTrigger installer, the ncdns installer doesn't show any visible warnings (other than a log message at the end (right before "Completed") saying "dnssec-trigger installation was NOT found, not configuring Unbound.").

It would be better UX for the ncdns installer to detect when a bundled installer has been canceled, and prompt the user to either retry or to choose a different option with respect to the bundled installers.

The bitcoinj-daemon.jar in our released 32-bit v0.0.5 binary seems to be built from a branch of bitcoinj-addons that doesn't support leveldbtxcache, so when it tries to set up the name database (after it's downloaded the blockchain) it crashes with an error about an invalid name lookup algorithm. Replacing the JAR with the one that's linked on the Namecoin website fixes it.

The JAR on the website is a little bit behind the latest Git code though... I wonder if I broke something in the latest bitcoinj-addons Git code.

Currently (as of #54 ) CTLPop/certinject (for negative overrides on CryptoAPI) are run as Administrator; we should switch to running them as sandboxed users.

The uninstaller should undo the certinject-based name constraint exclusion that the installer adds.

Right now, we ask the user to manually add an HPKP pin to Chromium. This has a few problems:

1. It will scare many users who aren't used to messing with Chromium settings.
2. If the user makes a mistake (e.g. failing to check the PKP checkbox), the user loses security.
3. The Chromium UI's HPKP pins expire after 1000 days. This means that the user loses security 1000 days after installing ncdns.

We should be able to install an HPKP pin automatically, which doesn't expire. I'll add details to this issue later on how exactly this can be done.

It seems that after uninstalling Dnssec-Trigger, DNS lookups don't work (possibly because the DHCP-supplied DNS servers aren't restored automatically). The DNS settings definitely do look correct when viewing the settings dialog, but it looks like they don't actually take effect and replace the 127.0.0.1 DNS until the network is disconnected+reconnected.

Tested with Dnssec-Trigger 0.14 beta. This is probably an upstream issue that we should report to NLnet Labs. Looks like bugs can be submitted here.

We should check the return code of subprocesses (e.g. spawned by nsExec::ExecToLog).

The rpccookiefile flag needs to be put before Sections [test] in namecoin.conf

Right now it look likes it just append the line at the end of the file if the file already exists.

Namecoin Core doesn't seem to create the QuietUninstallString registry value that NSIS recommends, which prevents ncdns-nsis from detecting how to uninstall it silently. May need to report this upstream to Bitcoin Core. Once it's fixed upstream, ncdns-nsis will need a patch to check for that value.

The chainloader for the Namecoin Core and Dnssec-Trigger installers isn't dropping its Administrator privileges before launching the installers. This seems to be causing a variety of unfortunate behavior, including a symptom where Namecoin Core's installer thinks that its AppData folder is located in ProgramData (which then causes permission errors the next time Namecoin Core is launched from the start menu, even after you later uninstall and reinstall Namecoin Core). And of course it's also bad from a security point of view.

Bitcoin Core actually has the same issue in their NSIS script (when it launches bitcoin-qt.exe at the end). I just submitted a PR to Bitcoin Core to fix that issue; if it passes peer review I'll adapt it for ncdns-nsis and submit a PR here as well.

Right now, we hardcode the profile folder paths of Chromium and Chrome.

This is a bad idea, because there are other Chromium forks (e.g. Opera) that use their own profile folder, and which we can otherwise support without any trouble. For example, Opera stores its HPKP list in AppData\Roaming\Opera Software\Opera Stable\TransportSecurity.

According to my brief testing, the following PowerShell one-liner will find all Chromium fork HPKP lists for a given user:

gci C:\Users\user\AppData -recurse -name -force -filter "TransportSecurity" -ErrorAction SilentlyContinue

It would probably make more sense to use this method rather than hardcoding the paths as we do now.

confd-list.conf has a double backslash between DnssecTrigger and unbound.conf.d.

I suspect that this is because in

These may be candidates for TransportSecurity HPKP injection.

• Opera
• https://www.startpage.com/do/search?q=list+of+chromium+forks&rl=to
  • Iridium Browser: https://iridiumbrowser.de/
  • https://wiki.installgentoo.com/index.php/Web_browsers
  • https://en.wikipedia.org/wiki/List_of_web_browsers
  • Slimjet: https://www.techsupportalert.com/content/new-chromium-based-browser-includes-add-ins-standard.htm
  • https://alternativeto.net/software/chromium/?platform=linux
• https://github.com/nylira/prism-break/search?q=browser&type=Issues&utf8=%E2%9C%93
  • ungoogled-chromium: prism-break/prism-break#1516
    • Inox patchset: https://github.com/gcarq/inox-patchset
  • Sware Iron: prism-break/prism-break#169
    • Epic Privacy Browser: http://epicbrowser.com/
  • Midori: prism-break/prism-break#88
  • WhiteHat Aviator: prism-break/prism-break#1175
  • Yandex: prism-break/prism-break#1207
  • QupZilla: prism-break/prism-break#559
  • Comodo Dragon: prism-break/prism-break#460

Inclusion on this scratchpad obviously doesn't constitute an endorsement. (I don't endorse any Chromium-based browsers, FWIW.)

NLnet Labs' Dnssec-Trigger website lists version 0.13 as the latest Windows release. Unfortunately, the official Windows binary of 0.13 is completely broken. Wouter Wijngaards from NLnet Labs is recommending that Windows users use a binary that he posted for version 0.14_20170106_2. Unfortunately, while that version works, it doesn't have hashes posted anywhere, which makes our distribution of it less easy to audit and reproduce. I reported this issue to NLnet Labs on 2017 Mar 27, but they haven't replied.

Might be worth filing a bug on NLnet Labs' bug tracker instead of using their mailing list.

The installer should give the user the option to upgrade the DnssecTrigger and Namecoin Core dependencies if the bundled versions are newer than the existing versions.

• DnssecTrigger
• Namecoin Core
• Electrum-NMC

When building ncdns-nsis on current Fedora, NSIS reports the warning ANSI targets are deprecated.

The custom "Components" form has a non-freedom build dependency (NSISDialogDesigner). We should replace that with a freedom software alternative.

The Makefile doesn't currently fetch namecoinj-daemon; this causes a build error unless the user adds it manually.

Chrome Canary has its own User Data folder, separate from Chromium and Chrome. According to https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md , Chrome Canary's User Data folder on Windows is %LOCALAPPDATA%\Google\Chrome SxS\User Data. As with Chromium and Chrome, multiple profiles can exist inside that folder.

We should support a bundled Electrum-NMC as an alternative to Namecoin Core and ConsensusJ-Namecoin.

Electron-based applications like Brave and Riot don't seem to store HPKP data in the same way that Chromium (and its forks) do. We should research whether there's a standard mechanism by which Electron does this, or if each application does its own thing. If there's a standard mechanism, we should try to support it.

@samurai321 sent me an install log for debugging purposes, and it looks like it didn't log anything about the Namecoin Core instance that was already installed. This caused me to spend a few minutes trying to figure out whether it actually detected the Namecoin node properly.

The NSIS script should log the following:

• An existing Namecoin Core node is detected.
• An existing Namecoin Core node is not detected.
• An existing Namecoin Core node is automatically configured.
• User chooses to manually provide a Namecoin node.

We should make sure that if CTLPop/certinject fail during install, NSIS detects this and fail the install.

Dnssec-Trigger 0.14 is released; we should upgrade to it.

In Silent Mode, both Namecoin Core and ConsensusJ-Namecoin get installed. This is presumably because the default is to do both, and this default behavior is replaced by the GUI page that asks the user. Obviously we should fix the default. Using Namecoin Core by default seems sane.

coredns-keygen looks like it might be a suitable Go-based replacement; it uses miekg/dns.

We should bundle dns-prop279.exe.

Right now, Silent mode doesn't install HTTPS support. I get that this is "experimental" code, but frankly this code has been tested a lot, and not enabling HTTPS by default in 2020 is irresponsible (and probably problematic for some certifications). We should enable it by default.

I just noticed that Chromium's TransportSecurity file isn't created when the rest of the profile is created, but instead is only created when the first HSTS or HPKP site is visited. This means that a stock installation of Chromium that hasn't visited any websites yet will not be detected by ncdns-nsis.

This is not likely to affect many real-world installations, because so many major sites (e.g. Google) use HSTS that I'm guessing almost all real-world Chromium installations have already created the TransportSecurity file. That said, at some point we might want to look into workarounds, e.g. creating the file ourselves if it doesn't exist but its directory does exist. Not an incredibly high priority IMO.

NO_DNSSEC_TRIGGER should be documented in the README.md "Build flags" section.

The current method of showing license information is non-standard. The correct/standard pattern for this in NSIS is to put this line between the MUI_PAGE_WELCOME and MUI_PAGE_DIRECTORY lines:

!insertmacro MUI_PAGE_LICENSE "ncdns_license.txt"

(ncdns_license.txt would presumably contain the text of the GPLv3+, as well as a preamble noting that Namecoin Core and Dnssec-Trigger have their own licenses.)

Hello I'm getting error when I try to compile .nsi file, becayse the Makefile is supplied with wrong URL for download which will throw an error.

Therefore I supplied all required files manually by downloading ncdns from namecoins beta section and extract it using 7zip.

the error I'm getting is

!define: "MUI_INSERT_NSISCONF"=""
!error: Must define NCDNS_PRODVER

any help please regarding this error since .nsi file contains a function to check

According to https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md , there can be multiple profiles in a Chromium or Chrome User Data folder, each of which is its own subdirectory. Each of those profiles has its own TransportSecurity file. On many systems (including mine), the initial profile is named Default, but @samurai321 reports that his system doesn't have a Default profile.

We should modify the code that searches for Chromium and Chrome installations so that it installs the HPKP pin in all profiles, not just a hardcoded Default profile.

It's not clear to me whether multiple profiles are a thing in Opera. Based on the directory structure, I'm guessing that they're not a thing.

Right now we're using the XP release of BIND as a dependency. I'm skeptical that the build toolchain/libraries that target XP are still reliably receiving security updates and other bugfixes. XP is EOL, so compatibility with XP shouldn't be a design goal for us. We should switch to the standard x86-32 and x86-64 releases of BIND. This should be as easy as switching the installer to check for Visual C Runtime 11.0 instead of 8.0 as we do right now, and updating the readme to point to the correct BIND binaries.

The regpermrun.ps1 hack for accessing both registry views shouldn't be necessary, because the registry key in question is shared between 32-bit and 64-bit registry views. (I incorrectly assumed earlier in development that they were separate registry keys.)

AdoptOpenJDK seems to be offering free binaries of OpenJDK, which are probably preferable over the non-free Oracle JDK that we've been testing with. We should test ncdns-nsis with AdoptOpenJDK, and implement any necessary fixes.

NO_NAMECOIN_CORE should be documented in the README.md "Build flags" section.

Imagine the following chain of events:

1. Phineas installs ncdns-nsis, with TLS enabled.
2. Phineas visits a .bit domain with TLS, but gets an error due to the system date/time being wrong. CryptoAPI caches the AIA URL's.
3. Phineas uninstalls and reinstalls ncdns-nsis, and fixes his date/time. By reinstalling ncdns-nsis, Phineas has rotated his Encaya keys.
4. Phineas now tries to visit the same .bit domain again.

Unfortunately, this results in an inconsistent state between the CryptoAPI AIA cache (which contains a Domain AIA Parent CA that is signed by the old Encaya key) and Encaya (which contains a .bit TLD CA with the new Encaya key). The result is that CryptoAPI will think the ECDSA signature on the Domain AIA Parent CA certificate is invalid.

In theory, the AIA cache will expire and this will fix itself, but the AIA cache does not appear to expire very quickly -- I waited an hour or so and it didn't help. However, we can flush the cache instantly by running this:

certutil -URLcache http://aia.x--nmc.bit/ delete

We should probably make ncdns-nsis run this command as part of the Encaya uninstallation routine. That ensures that whatever AIA cache mess was left by Encaya is gone when Namecoin is uninstalled.

Namecoin's bitcoinj-daemon requires Visual C++ 2010 Redistributable Package to be installed. If it isn't, bitcoinj-daemon will immediately exit with a really misleading error message. ncdns-nsis should check for its presence at the same time that we check for Java's presence.

The 64-bit version of ncdns-nsis is storing data in the registry key HKLM\SOFTWARE\Wow6432Node\Namecoin\ncdns. This should be changed to HKLM\SOFTWARE\Namecoin\ncdns since 64-bit software should be using the 64-bit registry view.

The ncdns uninstaller should remove all Namecoin certificate blobs from the Windows Registry, and remove the Namecoin HPKP pin from Chromium. (In that order.)

We should bundle cross_sign_name_constraint_tool.exe.

We should bundle tlsrestrict_nss_tool.exe.