Taking a break for a bit

2020-07-28 Thread Kevin J. McCarthy

Hi Everyone,

Just a heads-up that I'm going to take a few weeks off from Mutt 
development.  It's been consuming a large amount of my time, and I need 
some counterbalance to regain my perspective and get my motivation level 
back up.


I know I haven't been very good at bringing people onto the team.  Five 
years later, there ought to be more committers, reviewers, etc so I 
don't feel I have to do this alone.


I'd like to encourage people who have been participating in Mutt for a 
while (in any capacity) to talk to me, on- or off-list about becoming a 
team member.  The "Developer" role on gitlab can push to branches 
(besides master and stable), and I'm quite open to giving those out and 
working towards a "Maintainer" role.


I don't think any one person should have to lead the project until they 
burn out.  Ideally I would love to transition to just a developer in the 
next year or two.  :-)


Thank you all!

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: [PATCH] Support for overriding permissions of saved files

2020-07-28 Thread ilf
I agree. The default should be 0600. But users should be able to change 
it.


sacham...@s0c4.net:
Please don't take me wrong - I fully agree on default of 0600 for all 
created files (undoubtely mboxes). Yet even in my simple scenario 
(mutt got its own user profile) I need to be able to process stored 
attachments by other users (separate user for libreoffice, separate 
user for image viewer,...). Manually calling chmod *each and every 
time* is even more security-error-prone than being able to set umask 
once for time being.


--
ilf

If you upload your address book to "the cloud", I don't want to be in it.


Re: [PATCH] Support for overriding permissions of saved files

2020-07-28 Thread Steffen Nurpmeso
sacham...@s0c4.net wrote in
  <20200728180323.GE15493@lucid>:
 |The thread, and even older threads referenced there, is from 2007. \
 |Since then, the security field have evolved - now we have SeLinux, \
 |Apparmor and other techniques which are capable to provide even better \
 |security than umask(077) - I would say that ignoring shell's umask \
 |and enforcing our own may be actually harmful in above mentioned contexts.
 |
 |Please don't take me wrong - I fully agree on default of 0600 for all \
 |created files (undoubtely mboxes). Yet even in my simple scenario (mutt \
 |got its own user profile) I need to be able to process stored attachments \
 |by other users (separate user for libreoffice, separate user for image \
 |viewer,...). Manually calling chmod *each and every time* is even more \
 |security-error-prone than being able to set umask once for time being.
 |> 
 |We may even make this patch available only as by default disabled config\
 |ure option, I can imagine something like --enable-umask-override. How \
 |does that differ from applying my patch manually? Simply one does not \
 |have to trust "random patch from the internet", but supported option \
 |available for users who know what/why they want.

fwiw, for the MUA i maintain i implemented an umask override:

   umask
 For a safe-by-default policy the process file mode creation mask
 umask(2)[762] will be set to ‘0077’ on program startup after the
 resource files have been loaded, and unless this variable is set.
 By assigning this an empty value the active setting will not be
 changed, otherwise the given value will be made the new file mode
 creation mask.  Child processes inherit the file mode creation mask
 of their parent.

  ? xv var umask
  #nodelete,initial-value,positive-number
set umask=''

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


Re: [PATCH] Support for overriding permissions of saved files

2020-07-28 Thread sachamutt
The thread, and even older threads referenced there, is from 2007. Since then, 
the security field have evolved - now we have SeLinux, Apparmor and other 
techniques which are capable to provide even better security than umask(077) - 
I would say that ignoring shell's umask and enforcing our own may be actually 
harmful in above mentioned contexts.

Please don't take me wrong - I fully agree on default of 0600 for all created 
files (undoubtely mboxes). Yet even in my simple scenario (mutt got its own 
user profile) I need to be able to process stored attachments by other users 
(separate user for libreoffice, separate user for image viewer,...). Manually 
calling chmod *each and every time* is even more security-error-prone than 
being able to set umask once for time being.
> 
We may even make this patch available only as by default disabled configure 
option, I can imagine something like --enable-umask-override. How does that 
differ from applying my patch manually? Simply one does not have to trust 
"random patch from the internet", but supported option available for users who 
know what/why they want.

Regards,
Martin


On 20200728 0938, Will Yardley wrote:
> On Tue, Jul 28, 2020 at 06:18:59PM +0200, sacham...@s0c4.net wrote:
> > Thanks for replies, so what are the principal objections against such
> > option? Im curious because you said it was discussed several times,
> > which is clear indication of interest to have such a feature.
> 
> Have you tried searching the archives / doing a web search for past
> threads about this?
> 
> e.g.,
> https://www.mail-archive.com/search?l=mutt-dev@mutt.org=subject:%22Re%5C%3A+C%5BPATCH%5C%5D+Add+%24umask+for+mailboxes+and+attachments%22=newest=1
> 
> If you look towards the end of this thread, it alludes to earlier
> threads and some of the reasons. I'm sure you could find those
> discussions as well if you spend a couple of minutes.
> 
> I would guess that the objections mostly have to do with the security
> risks of allowing people to override this setting.
> 
> w
> 


signature.asc
Description: PGP signature


Re: [PATCH] Support for overriding permissions of saved files

2020-07-28 Thread Will Yardley
On Tue, Jul 28, 2020 at 06:18:59PM +0200, sacham...@s0c4.net wrote:
> Thanks for replies, so what are the principal objections against such
> option? Im curious because you said it was discussed several times,
> which is clear indication of interest to have such a feature.

Have you tried searching the archives / doing a web search for past
threads about this?

e.g.,
https://www.mail-archive.com/search?l=mutt-dev@mutt.org=subject:%22Re%5C%3A+%5C%5BPATCH%5C%5D+Add+%24umask+for+mailboxes+and+attachments%22=newest=1

If you look towards the end of this thread, it alludes to earlier
threads and some of the reasons. I'm sure you could find those
discussions as well if you spend a couple of minutes.

I would guess that the objections mostly have to do with the security
risks of allowing people to override this setting.

w



Re: [PATCH] Support for overriding permissions of saved files

2020-07-28 Thread sachamutt
Thanks for replies, so what are the principal objections against such option? 
Im curious because you said it was discussed several times, which is clear 
indication of interest to have such a feature.

Anyway, if anyone in future will find this thread, one can get the patch from 
my "web of patches": https://brmlab.cz/doku.php?id=user/sachy/lakatux#mutt

Regards,
Martin


On 20200728 0955, ilf wrote:
> FWIW: I would also like to be able to configure a different value. Hacing
> the default 0600 is fine, but being able to change it would be nice.
> 
> Best
> 
> Kevin McCarthy:
> > This request has been made repeatedly in the past, debated, and decided
> > against.  So, I don't think it's likely to gain much traction, or that
> > many people on the list are up for another debate about it.
> 
> -- 
> ilf
> 
> If you upload your address book to "the cloud", I don't want to be in it.


signature.asc
Description: PGP signature