* [ruby-core:84850] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
@ 2018-01-13 19:33 ` eregontp
2018-01-13 19:33 ` [ruby-core:84851] " eregontp
` (6 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: eregontp @ 2018-01-13 19:33 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been reported by Eregon (Benoit Daloze).
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:84851] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
2018-01-13 19:33 ` [ruby-core:84850] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility eregontp
@ 2018-01-13 19:33 ` eregontp
2018-01-13 22:24 ` [ruby-core:84852] " shevegen
` (5 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: eregontp @ 2018-01-13 19:33 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by Eregon (Benoit Daloze).
Assignee set to ko1 (Koichi Sasada)
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-69563
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:84852] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
2018-01-13 19:33 ` [ruby-core:84850] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility eregontp
2018-01-13 19:33 ` [ruby-core:84851] " eregontp
@ 2018-01-13 22:24 ` shevegen
2018-01-16 3:14 ` [ruby-core:84886] " ko1
` (4 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: shevegen @ 2018-01-13 22:24 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by shevegen (Robert A. Heiler).
I have seen $VERBOSE used in ways very similar as you described though and have used
it myself; most commonly I used it e. g. when I would use syck for yaml files rather
than psych, in order to suppress warnings I'd get during loading. It never felt very
elegant though to use the re-assignment trick. Can't think of a more elegant
solution either.
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-69567
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: 2.6
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:84886] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
` (2 preceding siblings ...)
2018-01-13 22:24 ` [ruby-core:84852] " shevegen
@ 2018-01-16 3:14 ` ko1
2018-01-16 17:14 ` [ruby-core:84892] " eregontp
` (3 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: ko1 @ 2018-01-16 3:14 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by ko1 (Koichi Sasada).
Assignee changed from ko1 (Koichi Sasada) to matz (Yukihiro Matsumoto)
Of course, I proposed `$SAFE` as `Fiber` local.
However, Matz said process global is enough.
akr also said nobody use `$SAFE` correctly, so that such incompatibility is not a matter.
I'm neutral. Matz, please decide it.
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-69593
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.6
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:84892] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
` (3 preceding siblings ...)
2018-01-16 3:14 ` [ruby-core:84886] " ko1
@ 2018-01-16 17:14 ` eregontp
2019-01-23 9:25 ` [ruby-core:91222] " v.ondruch
` (2 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: eregontp @ 2018-01-16 17:14 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by Eregon (Benoit Daloze).
> Of course, I proposed $SAFE as Fiber local.
:)
If $SAFE had no effect at all, then I think it would be fine to make $SAFE a normal process-wide global variable.
But this is not the case, $SAFE still causes SecurityError.
Therefore any library/code setting $SAFE will potentially break other threads, which is quite incompatible.
I think a more compatible way to remove $SAFE is:
* Warn that $SAFE is deprecated.
* Make it Fiber-local or Thread-local. (because very few people expect it frame-local and it incurs a cost)
* Warn that $SAFE is has no longer any effect (or maybe even raise when $SAFE is set, like for levels 2-4) and remove $SAFE checks, so the value of $SAFE has no effect.
* Remove the variable entirely or let it be process global.
Something like
ruby -e 'Thread.new{ $SAFE=1 }.join; Thread.new{ load "test.rb".taint }.join'
fails, prints no warning and could happen in any big application if $SAFE is set to 1 in some Thread.
This doesn't seem worth breaking. Even more so without a warning.
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-69600
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.6
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:91222] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
` (4 preceding siblings ...)
2018-01-16 17:14 ` [ruby-core:84892] " eregontp
@ 2019-01-23 9:25 ` v.ondruch
2019-02-07 5:23 ` [ruby-core:91447] " matz
2019-10-17 23:35 ` [ruby-core:95406] [Ruby master " merch-redmine
7 siblings, 0 replies; 8+ messages in thread
From: v.ondruch @ 2019-01-23 9:25 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by vo.x (Vit Ondruch).
Just FTR, as per this discussion:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/message/V234THAZ2ETTFVLJZXJYPH2QO5W7A3KL/
The global $SAFE breaks gettext testsuite:
https://github.com/ruby-gettext/gettext/commit/49b9f4ca66583395ddfa91503afd7593f069de18
As well as there are issues in postgresql-plruby:
https://github.com/devrimgunduz/postgresql-plruby/blob/master/extconf.rb#L21
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-76462
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:91447] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
` (5 preceding siblings ...)
2019-01-23 9:25 ` [ruby-core:91222] " v.ondruch
@ 2019-02-07 5:23 ` matz
2019-10-17 23:35 ` [ruby-core:95406] [Ruby master " merch-redmine
7 siblings, 0 replies; 8+ messages in thread
From: matz @ 2019-02-07 5:23 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by matz (Yukihiro Matsumoto).
I understand the compatibility situation. But I don't think it's worth effort for development. I vote for making $SAFE no effect (in 2.7).
Matz.
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-76707
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ruby-core:95406] [Ruby master Bug#14353] $SAFE should stay at least thread-local for compatibility
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
` (6 preceding siblings ...)
2019-02-07 5:23 ` [ruby-core:91447] " matz
@ 2019-10-17 23:35 ` merch-redmine
7 siblings, 0 replies; 8+ messages in thread
From: merch-redmine @ 2019-10-17 23:35 UTC (permalink / raw)
To: ruby-core
Issue #14353 has been updated by jeremyevans0 (Jeremy Evans).
Status changed from Open to Closed
`$SAFE` is being deprecated in 2.7 and will revert to normal global variable in 3.0, so this can be closed.
----------------------------------------
Bug #14353: $SAFE should stay at least thread-local for compatibility
https://bugs.ruby-lang.org/issues/14353#change-82149
* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In #14250 $SAFE changed from a frame+thread-local variable to a process-wide global variable.
This feels wrong and breaks the most common usage of $SAFE in tests:
~~~ ruby
Thread.new {
$SAFE = 1
sth that should be checked to work under $SAFE==1
}.join
~~~
It is very clear this is incompatible given how many files (33!) had to be changed in r61510.
And it has wide ranging confusing side-effects, one example: https://travis-ci.org/ruby/spec/jobs/328524568
I agree frame-local is too much for $SAFE.
But removing thread-local seems to only introduce large incompatibilities.
It also makes it impossible to use it in a thread-safe way.
The common pattern (not necessarily for $SAFE, more often for $VERBOSE):
~~~ ruby
begin
old = $SAFE
$SAFE = 1
something under SAFE==1
ensure
$SAFE = old
end
~~~
is unsafe if two threads run it concurrently (The last thread executing `$SAFE = old` might restore to 1 even though it should be 0).
(Actually I believe most built-in variables (e.g. $VERBOSE) should be thread-local and not process-wide due to this)
Since $SAFE is being deprecated and removed, I don't see any reason to make it more incompatible than needed.
@ko1 Can we switch it back to thread-local for compatibility, avoiding headaches and keeping it usable with multiple threads?
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-10-17 23:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <redmine.issue-14353.20180113193325@ruby-lang.org>
2018-01-13 19:33 ` [ruby-core:84850] [Ruby trunk Bug#14353] $SAFE should stay at least thread-local for compatibility eregontp
2018-01-13 19:33 ` [ruby-core:84851] " eregontp
2018-01-13 22:24 ` [ruby-core:84852] " shevegen
2018-01-16 3:14 ` [ruby-core:84886] " ko1
2018-01-16 17:14 ` [ruby-core:84892] " eregontp
2019-01-23 9:25 ` [ruby-core:91222] " v.ondruch
2019-02-07 5:23 ` [ruby-core:91447] " matz
2019-10-17 23:35 ` [ruby-core:95406] [Ruby master " merch-redmine
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 read-only IMAP folder(s) and NNTP newsgroup(s).