errata:
> Date: Sat, 26 Jun 2021 02:03:18 +1000 (+1000)
> From: Reuben ua Bríġ
> after learning that OpenSTMP had used sytem(3) rather than execv(3)
> resulting in a bug reminiscent of the morris-worm
i had guessed it was system(3), but having now seen the advisory:
Thank you for the detailed answer. I'll use this information to talk to xfce
devs and the maintainer if they could do anything to keep a consistent
experience in OpenBSD.
El June 25, 2021 5:28:00 PM UTC, Ingo Schwarze escribió:
>Hi,
>
>Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200:
Hi,
Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200:
> On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote:
>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine
>> with it. However, my date is expressed directly as it comes from date(1).
>> This is confirmed by
> And i am going to suggest you show a diff, and go through the process
> Ingo just described
as i said, i am new to this, and wanted to discuss something in words
before providing a C diff that would doubtless be rejected given that i
have only just begun to learn C.
i would have been happy to
Reuben ua Bríġ wrote:
> hi ingo, thanks for your reply.
>
> > I can't talk about the internals of the mount(2) syscall,
> > so i pass on that one to people who know better.
>
> !!! i feel i should emphasize,
> i am *not* presently suggesting any change to the mount(2) *system call*
> i *am*
hi ingo, thanks for your reply.
> I can't talk about the internals of the mount(2) syscall,
> so i pass on that one to people who know better.
!!! i feel i should emphasize,
i am *not* presently suggesting any change to the mount(2) *system call*
i *am* suggesting a change to the mount(8)
Hi,
Reuben ua Brig wrote:
> when OpenBSD is happy to change even man.conf
We change things when all of the following hold:
1. There is a significant problem to be solved, or a significant
profit to be gained. Regarding man.conf: the old format was
over-engineered, wordy, hard to use,
> If your proposal is to error when the check fails, it will break
> hundreds of user machines.
>
> If your proposal is to emit a warning, it will emit multiple
> additional lines of output at boot for correct existing
> configurations.
>
> But you didn't implement a prototype, you didn't test
Reuben ua Bríġ wrote:
> > I wonder why noone implimented such checks like that in the last 30
> > years. Might be because it breaks more than it fixes.
>
> i cant tell if you are being sarcastic or what it could possibly break
> or why that would matter when OpenBSD is happy to change even
> I wonder why noone implimented such checks like that in the last 30
> years. Might be because it breaks more than it fixes.
i cant tell if you are being sarcastic or what it could possibly break
or why that would matter when OpenBSD is happy to change even man.conf
Reuben ua Bríġ wrote:
> > Probably because testing for the situation would be an unreliable
> > race. BTW, you explain the ssh behaviour incorrectly. It does not
> > warn. It fails, and refuses to continue. Failure is not permitted
> > for the mount system call in this circumstance, and the
> Probably because testing for the situation would be an unreliable
> race. BTW, you explain the ssh behaviour incorrectly. It does not
> warn. It fails, and refuses to continue. Failure is not permitted
> for the mount system call in this circumstance, and the entire path
> upwards cannot be
Reuben ua Bríġ wrote:
> mount(8) will follow a symlink(7), so obviously it is *very* stupid to
> mount under a directory a user other than root has write permission for,
> as they could, for example
>
> rm -rf path
> ln -s /etc path
>
> ? so why doesnt the man page for mount(8)
mount(8) will follow a symlink(7), so obviously it is *very* stupid to
mount under a directory a user other than root has write permission for,
as they could, for example
rm -rf path
ln -s /etc path
? so why doesnt the man page for mount(8) mention anything.
? why doesnt mount(8)
June 25, 2021 5:08 AM, "Samuel Banya" wrote:
>
> [...]
>
> Here is the output of running the following command in
> '/usr/local/dovecot/sieve' as the 'root'
> user on the box, but received the following message:
> #+BEGIN_SRC bash
> l# sievec report-ham.sieve
> report-ham: line 1: error:
On 2021-06-25, gil...@poolp.org wrote:
> June 25, 2021 5:08 AM, "Samuel Banya" wrote:
>
>>
>> [...]
>>
>> Here is the output of running the following command in
>> '/usr/local/dovecot/sieve' as the 'root'
>> user on the box, but received the following message:
>> #+BEGIN_SRC bash
>> l# sievec
On 2021-06-25, Theo Buehler wrote:
> If we want to go the cherry-picking route, here's a diff that fixes the
> test.csv.gz test case provided in the linked issue.
No objection to this (it won't make a future sync much harder, there
are already many changes in openbsd-zlib compared to the more
17 matches
Mail list logo
