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" <[email protected]> >>>> To: [email protected] >>>> 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#L170 >>>> >>>> >>>> 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/fedora-rawhide-x86_64/00843822-rubygem-gettext/ >>> >>> 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/49b9f4ca66583395ddfa91503afd7593f069de18 >> >> >> 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.
https://src.fedoraproject.org/rpms/postgresql-plruby/c/a5cb8b7d06ba8debadf72a31dc9b304a1d0cb29f?branch=master 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 _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
