Thanks a lot for this really quick fix Dima. I gave it positive review
already.
On Friday, April 12, 2024 at 4:27:31 PM UTC+3 Georgi Guninski wrote:
My results differ. If you want more systematic approach for QA and security
(the recent paranoia induced by the xz backdoor) you will need
My results differ. If you want more systematic approach for QA and security
(the recent paranoia induced by the xz backdoor) you will need moderate
budget possibly with zero trust to me.
Have a nice weekend.
On Fri, Apr 12, 2024 at 3:52 PM Dima Pasechnik wrote:
>
>
>
> On 12 April 2024 12:42:39
On 12 April 2024 12:42:39 CEST, Georgi Guninski wrote:
>On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik wrote:
>>
>> This should be fixed by https://github.com/sagemath/sage/pull/37792
>> please review
>>
>
>I suspect reproducing is hard, since it depends on the time of pressing CTL-C.
Well,
On Fri, Apr 12, 2024 at 11:35 AM Dima Pasechnik wrote:
>
> This should be fixed by https://github.com/sagemath/sage/pull/37792
> please review
>
I suspect reproducing is hard, since it depends on the time of pressing CTL-C.
Also, lack a crash may be silent memory corruption.
It is weird that
This should be fixed by https://github.com/sagemath/sage/pull/37792
please review
On Thursday, April 11, 2024 at 10:19:31 PM UTC+1 dim...@gmail.com wrote:
> On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote:
> > Are the non-crashing codepaths in consistent state?
> > SEGV is in
On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote:
> Are the non-crashing codepaths in consistent state?
> SEGV is in general sign of memory corruption and it may lead to wrong
> math results or possibly have security implications.
Here is an attempt to fix it; it appears that the
Are the non-crashing codepaths in consistent state?
SEGV is in general sign of memory corruption and it may lead to wrong
math results or possibly have security implications.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from
On Thu, Apr 11, 2024 at 09:27:15AM +0300, Georgi Guninski wrote:
> Giving short testcase, can someone else reproduce it?
> Also attaching backtrace.
yes, I can reproduce this on a recent 10.4.beta - the backtrace I get it
more or less the same as the one attached - and it's in an unexpected to
me
Giving short testcase, can someone else reproduce it?
Also attaching backtrace.
On second thought, if I don't crash, there could be some memory
corruption and sage runs with screwed memory.
```
x,y=var('x,y');n=10**6
while True: so=solve_mod(x*y-1,n)
#press CTL-C, crashes with probability about
Also not that there is plenty of code that, in the course of computation,
writes into attributes of objects. If you're doing multiple of those it's
very hard in python to make such a modification atomic. So if an interrupt
ends up splitting an update, you may leave the system in an inconsistent
I do not remember anything specific about solve_mod. Though, there are
many places in Cython source code where sig_on/sig_off is not handled
carefully enough (and many that were fixed).
The fact that it is not reproducible is not necessarily a huge problem. However,
- Could you share the code (as
I don't have reproducible testcase, but my pain is that sometimes if I
press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
abort.
I suspect besides signals, it is hitting race condition.
Is this a known issue?
Very long ago there was vulnerability in sendmail, where it did
12 matches
Mail list logo
