[hackers] Re: [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

2020-08-17 Thread Armin Friedl
Sorry for the spam. My sendmail wasn't set up correctly and went rogue when it started to work. On 8/17/20 10:58 PM, Armin Friedl wrote: > Currently, maxnprocs may actually lower the limit. Especially when using the > default limit of 512, this quickly causes quark's fork() to fail when started >

[hackers] [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

2020-08-17 Thread Armin Friedl
Currently, maxnprocs may actually lower the limit. Especially when using the default limit of 512, this quickly causes quark's fork() to fail when started with a non-exclusive user. To mitigate this, we respect system defaults and only raise the limit if it is an actual raise. --- main.c | 25

[hackers] [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

2020-08-17 Thread Armin Friedl
Currently, maxnprocs may actually lower the limit. Especially when using the default limit of 512, this quickly causes quark's fork() to fail when started with a non-exclusive user. To mitigate this, we respect system defaults and only raise the limit if it is an actual raise. --- main.c | 25

[hackers] [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

2020-08-17 Thread Armin Friedl
Currently maxnprocs may actually lower the limit. Especially when using the default limit of 512, this quickly causes quark's fork() to fail when started with a non-exclusive user. To mitigate this, we respect system defaults and only raise the limit if it is an actual raise. --- main.c | 25

[hackers] [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

2020-08-17 Thread Armin Friedl
Currently maxnprocs may actually lower the limit. Especially when using the default limit of 512, this quickly causes quark's fork() to fail when started with a non-exclusive user which may easily have a couple hundred process running before even starting quark. To mitigate this, we respect

[hackers] [quark] Implement RFC 8615 (Well-Known URIs) and refine access errors || Laslo Hunhold

2020-08-17 Thread git
commit 3bd49b24561ce3c7be916ab0abbc78288721ddc4 Author: Laslo Hunhold AuthorDate: Mon Aug 17 10:33:55 2020 +0200 Commit: Laslo Hunhold CommitDate: Mon Aug 17 10:39:54 2020 +0200 Implement RFC 8615 (Well-Known URIs) and refine access errors We generally rejected any URI that

[hackers] [quark] Reduce global state by localizing the server-struct || Laslo Hunhold

2020-08-17 Thread git
commit 65600ffe7a2868e95cf172550c85aa074e209e0d Author: Laslo Hunhold AuthorDate: Mon Aug 17 11:37:25 2020 +0200 Commit: Laslo Hunhold CommitDate: Mon Aug 17 11:37:25 2020 +0200 Reduce global state by localizing the server-struct The server-struct variable s was global,

Re: [hackers] [quark][PATCH] Don't reject /.well-known/ (see RFC 8615)

2020-08-17 Thread Laslo Hunhold
On Sat, 15 Aug 2020 15:32:11 -0700 robert wrote: Dear Robert, thanks for your patch! > Previously, all hidden targets were rejected with 403, but > /.well-known/ and its contents should be an exception. > > - /* reject hidden target */ > - if (realtarget[0] == '.' || strstr(realtarget,

Re: [hackers] [quark] Reduce global state by localizing the server-struct || Laslo Hunhold

2020-08-17 Thread Jeremy
Then should the functions which use the global variable, "term", in st.c accept a Term pointer instead? In the case of st, I believe this may affect readability slightly, however, it would allow for some extensibility(if dvtm, for example, wanted to rewrite its terminal implementation). I'm not

Re: [hackers] [quark] Reduce global state by localizing the server-struct || Laslo Hunhold

2020-08-17 Thread Laslo Hunhold
On Mon, 17 Aug 2020 03:47:27 -0700 Jeremy wrote: Dear Jeremy, thanks for your feedback. In any case, before diving into this topic, st's maintainer (Hiltjo) has the final say on these things. It's not a clear-cut debate and depends largely on personal taste and practicality. > Then should the

Re: [hackers] [quark] Reduce global state by localizing the server-struct || Laslo Hunhold

2020-08-17 Thread Hiltjo Posthuma
On Mon, Aug 17, 2020 at 03:47:27AM -0700, Jeremy wrote: > Then should the functions which use the global variable, "term", in st.c > accept a Term pointer instead? > > In the case of st, I believe this may affect readability slightly, > however, it would allow for some extensibility(if dvtm, for