Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/duckdns: init module #294489

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

nixos/duckdns: init module #294489

wants to merge 2 commits into from

Conversation

notthebee
Copy link

Description of changes

Added a Systemd service for updating DuckDNS domains

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@notthebee notthebee changed the title nixos/duckdns: init nixos/duckdns: init module Mar 9, 2024
@notthebee notthebee marked this pull request as ready for review March 9, 2024 12:32
nixos/modules/misc/ids.nix Outdated Show resolved Hide resolved
nixos/modules/misc/ids.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Show resolved Hide resolved
Copy link
Contributor

@bjornfor bjornfor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Echoing the query string like this exposes the secret to all (unprivileged) processes on the system -- can we avoid that?

If not, please add a big warning in the option description.

@bjornfor
Copy link
Contributor

You updated at the same time I commented 😀

However, the secret is still visible in process listings.

@bjornfor
Copy link
Contributor

I think "curl -K ./secret_params.txt ..." where secret_params.txt contains lines of "-d key=value" is the way to go. "replace-secret" in nixpkgs might help with securely preparing the file. (Untested.)

@notthebee
Copy link
Author

Used the -K parameter and some shell redirection to hide the secrets in the process list

@bjornfor
Copy link
Contributor

Used the -K parameter and some shell redirection to hide the secrets in the process list

Thanks!

Please rebase / squash the commits and I can take another look. (I think those 11 commits are just fixups to the one "init" commit?)

@notthebee
Copy link
Author

Used the -K parameter and some shell redirection to hide the secrets in the process list

Thanks!

Please rebase / squash the commits and I can take another look. (I think those 11 commits are just fixups to the one "init" commit?)

Done :)

nixos/modules/services/misc/duckdns.nix Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
nixos/modules/services/misc/duckdns.nix Outdated Show resolved Hide resolved
Comment on lines 54 to 61
{
assertion = cfg.domains != null || cfg.domainsFile != null;
message = "Either services.duckdns.domains or services.duckdns.domainsFile has to be defined";
}
{
assertion = !(cfg.domains != null && cfg.domainsFile != null);
message = "Only one of services.duckdns.domains and services.duckdns.domainsFile can be defined";
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I know this is about the third time someone has commented on these assertions. Hopefully final time.

Suggested change
{
assertion = cfg.domains != null || cfg.domainsFile != null;
message = "Either services.duckdns.domains or services.duckdns.domainsFile has to be defined";
}
{
assertion = !(cfg.domains != null && cfg.domainsFile != null);
message = "Only one of services.duckdns.domains and services.duckdns.domainsFile can be defined";
}
{
assertion = lib.xor (cfg.domains != null) (cfg.domainsFile != null);
message = "Only one of services.duckdns.domains and services.duckdns.domainsFile can be defined";
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think with the xor assert, the error message gets slightly confusing. I tried rewording it to One of services.duckdns.domains and services.duckdns.domainsFile must be defined, but not both, but I'm not happy with that either. (Think of the case when neither is set.) So I think I prefer separate assert/message. (But no strong feelings, just ignore if you want.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On one hand, it feels overkill having two assertions to cover for what is essentially one assertion (or at least it is in my head), but you do have a good point about the error message. I'll leave the decision to the PR author. Sorry about the additional noise and iteration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants