Github messages for voidlinux
 help / color / mirror / Atom feed
From: edneville <edneville@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: New package: please-0.3.16
Date: Thu, 10 Dec 2020 22:23:51 +0100	[thread overview]
Message-ID: <20201210212351.qWznvKPdE4es8I3P_3x9cU-dQ4HCQcIMnfQ8fFLr2Dk@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-27037@inbox.vuxu.org>

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

New comment by edneville on void-packages repository

https://github.com/void-linux/void-packages/pull/27037#issuecomment-742808466

Comment:
@ericonr:
> Yes, there's something to be said for providing simpler security tools that can greatly increase the general security, due to being simpler to deploy. At the same time, we still have to minimally ensure that these tools don't introduce new holes.

This is a good attitude, and one that makes me confident in Void for the same reasons that I like Debian.

> Since you're introducing a new tool into the field, the burden of proof for that is mostly on you. If I don't merge this new package, not much changes, and people who really want it can install it from elsewhere. If we do merge this package and someone finds an exploit or issue with it, then we (Void) share the responsibility for the number of affected people, since including it in our repository counts as vetting it.  

The codebase is particularly small if that helps reduce concerns over attack surface, really Rust's Regex is doing the heavy lifting here.

@travankor:
> Note that Void has [opendoas](https://github.com/duncaen/opendoas), based on a similar tool in OpenBSD's src.

I've looked at doas, which, for similar reasons to this project desired a smaller code base than sudo.

> Secondly, there seems to already be a similar, older tool called [please](https://github.com/gblach/please), packaged in FreeBSD, which can be a source of confusion for everyone. This project is called `pleaser` on crates.io, so I don't know what the reason is for the dual naming scheme.

I used 'please' in as I thought that if someone wanted a sandwich they should ask 'please' first :) As I'm now aware of prior naming I'll update the project name where it isn't already 'pleaser'.

I was aware of 'doas' but not that FreeBSD had a tool named 'please' too, I suppose it came from similar thinking.

Importantly for this project, neither doas or gblach's please have regex command matching. doas is more limited than 'sudo' in that you cannot specify a range either, but if someone uses wildcards in a sudo argument without negations afterwards will likely suffer unfairly. This effort is to improve things, hopefully with a small codebase there will be fewer pains all round.

  parent reply	other threads:[~2020-12-10 21:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 19:14 [PR PATCH] " edneville
2020-12-08 19:16 ` [PR PATCH] [Updated] " edneville
2020-12-08 19:24 ` edneville
2020-12-08 19:34 ` edneville
2020-12-08 20:15 ` [PR REVIEW] " ericonr
2020-12-08 20:15 ` ericonr
2020-12-08 20:15 ` ericonr
2020-12-08 20:15 ` ericonr
2020-12-09 18:43 ` [PR PATCH] [Updated] " edneville
2020-12-09 18:53 ` edneville
2020-12-09 19:29 ` ericonr
2020-12-09 21:04 ` edneville
2020-12-10  0:11 ` ericonr
2020-12-10  5:05 ` travankor
2020-12-10 21:10 ` [PR PATCH] [Updated] " edneville
2020-12-10 21:23 ` edneville [this message]
2020-12-11 19:13 ` [PR PATCH] [Updated] New package: please-0.3.17 edneville
2021-01-26 17:17 ` edneville
2021-01-29 19:36 ` edneville
2021-01-30 13:51 ` edneville
2021-03-02 18:46 ` edneville
2021-03-06 17:52 ` edneville
2021-03-11 19:12 ` [PR PATCH] [Updated] " edneville
2021-04-18 23:42 ` ericonr
2021-04-18 23:42 ` [PR PATCH] [Closed]: " ericonr

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=20201210212351.qWznvKPdE4es8I3P_3x9cU-dQ4HCQcIMnfQ8fFLr2Dk@z \
    --to=edneville@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).