> On Nov 2, 2017, at 10:35 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Thu, Nov 2, 2017 at 11:34 PM, Craig Russell <apache....@gmail.com> wrote:
>>
>>> On Nov 2, 2017, at 4:24 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> On Thu, Nov 2, 2017 at 6:58 PM, Craig Russell <apache....@gmail.com> wrote:
>>>> The error appears to be here:
>>>>
>>>> # untaint to email addresses
>>>> mail.to = mail.to.map {|email| email.dup.untaint} <== here
>>>>
>>>> But the mail.to should be r...@apache.org
>>>
>>> mail.to is normally an array of values. In this case, it is a string
>>> containing the bulk of the headers and body of the message.
>>
>> Why does email to: contain all that stuff?
>
> Properly formatted emails terminate lines in \r\n. The template ends
> lines with \n.
The template code:
def template(name)
path = File.expand_path("../templates/#{name}", __FILE__.untaint)
ERB.new(File.read(path.untaint).untaint).result(binding)
end
Could this be changed to replace all \n with \r\n here?
Craig
> Properly formatted emails also are pure ASCII; emails have a strange
> convention for escaping non-ASCII characters.
>
> Previous versions of the mail gem recovered from both cases. Recent
> changes made it so that it will recover from one or the other, but not
> both simultaneously. I plan to build a pull request for the mail gem
> tomorrow to address this.
>
>> Given that the email to: was created in line 221, I don't understand why it
>> needs to be untainted.
>>>
>>>> Why does this need to be untainted? Why does it fail just on this email?
>>>> The only thing different about this email is the non-ascii characters in
>>>> the name...
>>>
>>> Bug reported against mail gem:
>>> https://github.com/mikel/mail/issues/1167. The existence of non-ASCII
>>> characters and the absence of CR's appear to be involved. I want to
>>> think briefly about whether it would be better to pin to an older
>>> version of this gem (which would work, but would mean that we wouldn't
>>> get bug fixes), or to find a reasonable workaround.
>>
>> What bad would happen if line 232 were removed? Could the
>> template('acreq.erb') be untainted by itself? mail cc: is untainted in line
>> 229.
>
> https://lists.apache.org/thread.html/cf99af41102e58ffe3e3e98afa1d9861590c232373f92f079341fe3f@%3Cdev.whimsical.apache.org%3E
>
> There may indeed be other ways to untaint this value, perhaps
> untainting the whole template might indeed work; but first we need
> either have the template produce a more RFC compliant email or to make
> the mail gem handle what the template does produce. As it stands now,
> the mail gem will take the entire rest of the file and store it into
> the to: address, which will fail later even if this were untainted.
>
>> Craig
>>
>>>
>>>> Craig
>>>
>>> - Sam Ruby
>
> - Sam Ruby
>
>>>>> On Nov 2, 2017, at 3:31 PM, Craig Russell <apache....@gmail.com> wrote:
>>>>>
>>>>> Hi Sam,
>>>>>
>>>>>> On Nov 2, 2017, at 12:08 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>
>>>>>> Reproduction instructions?
>>>>>
>>>>> Try to file the icla from Nandor Kollar.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Craig
>>>>>>
>>>>>> - Sam Ruby
>>>>>>
>>>>>> On Thu, Nov 2, 2017 at 11:27 AM, Craig Russell <apache....@gmail.com>
>>>>>> wrote:
>>>>>>> #<NoMethodError: undefined method `map' for #<String:0x007f9ba34add28>
>>>>>>> Did you mean? tap>
>>>>>>> /x1/srv/whimsy/www/secretary/workbench/views/actions/icla.json.rb:232:in
>>>>>>> `block in _evaluate'
>>>>>>> /x1/srv/whimsy/www/secretary/workbench/tasks.rb:9:in `task'
>>>>>>> /x1/srv/whimsy/www/secretary/workbench/views/actions/icla.json.rb:221:in
>>>>>>> `_evaluate'
>>>>>>> /x1/srv/whimsy/www/secretary/workbench/server.rb:68:in `block in <top
>>>>>>> (required)>'
>>>>>>> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:223:in `call'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/rack/out_of_band_gc.rb:48:in
>>>>>>> `call'
>>>>>>> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:148:in `call'
>>>>>>> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:79:in `call'
>>>>>>> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:254:in `call'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in
>>>>>>> `process_request'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:160:in
>>>>>>> `accept_and_process_next_request'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:113:in
>>>>>>> `main_loop'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/request_handler.rb:416:in
>>>>>>> `block (3 levels) in start_threads'
>>>>>>> /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.1.8/src/ruby_supportlib/phusion_passenger/utils.rb:113:in
>>>>>>> `block in create_thread_and_abort_on_exception'
>>>>>>>
>>>>>>> Craig L Russell
>>>>>>> Secretary, Apache Software Foundation
>>>>>>> c...@apache.org http://db.apache.org/jdo
>>>>>>>
>>>>>
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> c...@apache.org http://db.apache.org/jdo
>>>>
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> c...@apache.org http://db.apache.org/jdo
>>>>
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo
