Github messages for voidlinux
 help / color / mirror / Atom feed
From: rvighne <rvighne@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: dnsmasq: enable dnssec build option by default
Date: Sun, 12 Mar 2023 22:01:00 +0100	[thread overview]
Message-ID: <20230312210100.OpnFOVcpdXsoPI6vbbpnAdCxS9MZQB7DSHPdJQubOk0@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-41786@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

New comment by rvighne on void-packages repository

https://github.com/void-linux/void-packages/pull/41786#issuecomment-1465298617

Comment:
> Don't ping people just because they touched a template. We're a small, volunteer group without strict procedures for review and acceptance. People get to things when they get to them. When somebody comes along that has an interest in this package and in your change to the default build options, that person will likely comment or merge the changes.

Understood. Though I don't see how a new contributor could tell the difference between "reviewers have seen this but they're busy so they'll get to it eventually" and "there's something wrong with this PR so nobody's reviewing it".

> I have no idea whether enabling this option by default will break somebody's workflow. You show that the option works when you enable it, but offer no comments about what impact this change might have in existing users.

This option enables a feature that is disabled by default unless you have `dnssec` in the config file. It's not possible that someone already had this option enabled and their dnsmasq instance will suddenly start to behave differently, because non-dnssec-capable builds of dnsmasq will fail to start up if given that flag.

Enabling the dnssec build option also has the side effect of adding `nettle` as a dependency, which is tiny (600KB).

Also, it's pretty unlikely in 2023 that you would want to set up a DNS resolver that ignores DNSSEC. I don't know if Void has any guidelines for this type of thing, but having secure defaults (and not making users build their own package just to get a basic security feature) seems like a good idea to me.

  parent reply	other threads:[~2023-03-12 21:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21 21:49 [PR PATCH] " rvighne
2023-02-12 20:29 ` [PR PATCH] [Updated] " rvighne
2023-02-12 20:30 ` rvighne
2023-02-12 20:39 ` rvighne
2023-02-12 22:32 ` [PR REVIEW] " ahesford
2023-03-12 20:43 ` rvighne
2023-03-12 21:01 ` rvighne [this message]
2023-06-11  2:09 ` github-actions
2023-06-25  2:12 ` [PR PATCH] [Closed]: " github-actions
2023-06-25  2:14 ` [PR REVIEW] " abenson
2024-06-20 17:48 [ISSUE] dnsmasq needs to be built with DNSSEC support uhohspaghetios
2024-06-23 11:08 ` dnsmasq: enable DNSSEC build option by default piekay
2024-06-26 13:53 ` uhohspaghetios
2024-06-26 13:53 ` uhohspaghetios
2024-06-26 13:54 ` uhohspaghetios
2024-06-26 14:05 ` classabbyamp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230312210100.OpnFOVcpdXsoPI6vbbpnAdCxS9MZQB7DSHPdJQubOk0@z \
    --to=rvighne@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).