Dne 23. 01. 19 v 10:29 Vít Ondruch napsal(a):
Dne 22. 01. 19 v 21:54 Mamoru TASAKA napsal(a):
> Pavel Valena wrote on 2019/01/23 4:32:
>> ----- Original Message -----
>>> From: "Vít Ondruch" <vondruch(a)redhat.com>
>>> To: ruby-sig(a)lists.fedoraproject.org
>>> Sent: Tuesday, January 22, 2019 4:26:13 PM
>>> Subject: Re: Ruby 2.6 - Mass rebuild - postgresql-plruby
>>>
>>>
>>>
>>>
>>> Dne 22. 01. 19 v 9:59 Mamoru TASAKA napsal(a):
>>>
>>>
>>>
>>> 3 postgresql-plruby-0.5.7-1.fc30.src.rpm
>>> Build fails:
>>>
https://koji.fedoraproject.org/koji/taskinfo?taskID=32181377
>>> Succeeds for rawhide (ruby2.5)
>>>
https://koji.fedoraproject.org/koji/taskinfo?taskID=32181375
>>> + ruby extconf.rb --vendor --with-safe-level=1
>>> --with-pg-config=/usr/bin/pg_server_config
>>> ...
>>> ...
>>> BUILDSTDERR: extconf.rb:175:in `directory?': Insecure operation -
>>> directory?
>>> (SecurityError)
>>> Perhaps related to ruby changes with regard to security model.
>>>
>>>
>>>
>>>
>>>
>>>
>>> This is interesting issue. It fails at this line:
>>>
>>>
https://github.com/devrimgunduz/postgresql-plruby/blame/master/extconf.rb...
>>>
>>>
>>> Similar reproducer IMO could be:
>>>
>>> ~~~
>>>
>>>
>>> $ ruby -e '$SAFE=1; Dir.foreach(".") {|d|
File.directory?(d)}'
>>>
>>> ~~~
>>>
>>> This fails on Ruby 2.5 as well as Ruby 2.6, what is somehow expected
>>> given
>>> that the `d` is tainted. However, how comes that it passes in the
>>> extconf.rb
>>> for Ruby 2.5?
>>>
>>> IOW the workarond/fix could be as simple as ` dir.untaint` but it
>>> does not
>>> explain why it worked and does not work anymore :/ Thoughts?
>>>
>>>
>>>
>>>
>>> Vít
>> Maybe I'm being silly, but doesn't it correspond to:
>>
>> - $SAFE is a process global state and we can set 0 again. [Feature
>> #14250] [1]
>>
>> or to some of the related revisions, like $SAFE in ERB being deprecated?
>> (Note: procs, lambdas, threads, all share the same $SAFE level; and
>> SAFE 1 and 0 are both considered 'unsafe'.)
>>
>> I've seen 'Insecure operation' warnings in rubygem-gettext build
>> too[2], but I do not yet know how to fix them.
>>
>> [1]
https://bugs.ruby-lang.org/issues/14250
>> [2]
>>
https://copr-be.cloud.fedoraproject.org/results/pvalena/ruby26-gems/fedor...
>>
>> Regards,
>> Pavel
> Well, I didn't know now rubygem-gettext fails to build with ruby 2.6 -
> but perhaps the upstream commit
> below will fix the issue:
>
https://github.com/ruby-gettext/gettext/commit/49b9f4ca66583395ddfa91503a...
>
>
> So as Pavel says, ruby 2.6 change says $SAFE is now global, so with
> the following line:
>
https://github.com/devrimgunduz/postgresql-plruby/blob/master/extconf.rb#L21
>
>
> I guess in ruby 2.5, $SAFE was 1 on this thread, but with ruby 2.6
> $SAFE becomes 1 on global (I guess)
Ah, now it starting to make sense.
So the correct fix should be adding "ensure $SAFE=0" or probably the
previous safe level should be cashed? Actually reading [1], it seems
that the whole thread stuff should be dropped. The thread was used just
to avoid influence of the $SAFE == 1 on the rest of the script, which
does not work anymore because of the $SAFE global scope, but now we can
simply change the value to different safe level, which was previously
not possible.
Not sure if there is more elegant way, but I doubt we can somehow query
$SAFE capabilities.
Anyway, this one should be resolved for now.
Vít