Project

General

Profile

DevelopersMeeting20130215

This meeting will be held on 2013-02-15 at 15:00 Pacific Time) at ((<URL:irc://chat.freenode.net/#ruby-implementers).

EN <=> JA translations will be done on demand in #ruby-ja on ircnet

Attendees

MRI

  • tenderlove (Aaron Patterson)
  • matz
  • mame (Yusuke Endoh)
  • mrkn (Kenta Murata), if I can get up early.
  • emboss (Martin Boßlet)
  • ko1
  • marcandre (Marc-André Lafortune)
  • eregon (Benoit Daloze)
  • kosaki

Rubinius

  • dbussink (Dirkjan Bussink)

JRuby

  • headius (Charles Oliver Nutter)
  • enebo (Thomas E. Enebo)

MagLev

  • phlebas (Tim Felgentreff)

MacRuby

  • jballanc (Josh Ballanco)

Topaz

  • Alex_Gaynor

mruby

  • bovi (Daniel Bovensiepen)

Moderator

  • zenspider (Ryan Davis)

Agenda

We'll keep this meeting to one hour long.

IRC Log

15:06 zenspider: ok. we start... tenderlove ... intro
please
15:06 enebo: agreed
15:06 tenderlove: okay
15:06 tenderlove: so
15:06 tenderlove: based on feedback from the last
meeting
15:07 tenderlove: we're not going to have strict
moderation
15:07 zenspider: FIFTY FIVE MINUTES REMAINING! :P
15:07 tenderlove: zenspider will moderate, but he's just
going to make sure that we stay on topic
15:07 tenderlove: and that we don't spend too much time on
any one topic
15:07 tenderlove: the agenda is here:
https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130215
15:08 zenspider: we've got 10 bullet points, so 6 minutes
per, tho we're starting a bit late
15:08 tenderlove: also based on feedback I got, there should
be redmine tickets for (most) of these
15:08 zenspider: luckily intro and wrapup are fast
15:08 tenderlove: so we can continue discussion later
15:08 tenderlove: so, that said, let's get started
15:08 tenderlove: I guess Ruby 2 version scheme is
first
15:08 tenderlove: I don't know who added that though...
15:08 zenspider: topic: Ruby 2 versioning scheme, like 1.x
(no number > 9)? Will 2.0.10 or 2.10.0 be
allowed?
15:09 tenderlove: ko1: ?
15:09 zenspider: I'm not strictly moderating, so speak
freely
15:09 ko1: no. but i think it is matz's matter
15:09 zenspider: I'll just keep the topics flowing
15:09 enebo: one question....
15:09 zenspider: we'll move that to the end
15:09 enebo: Is there any techincal reason why 2.10 would
cause issues with existing software for version
checks?
15:10 zenspider: (afaik string sorts)
15:10 mame0: it looks just a matter of taste
15:10 enebo: If not then it is political discussion
15:10 mame0: just ask matz!
15:10 enebo: yes
15:10 zenspider: we'll wait for matz and put that later
15:10 zenspider: topic: Ruby Symbol issues (tenderlove)
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/52165
15:10 tenderlove: alright, so I asked about a thing to freeze
/ thaw symbol creation
15:11 tenderlove: basically on Rails team we have to play
"whack a mole"
15:11 tenderlove: finding places where we didn't think
foreign input could go
15:11 tenderlove: and we happen to be "to_sym" that
thing
15:11 tenderlove: I proposed a freeze / thaw so we could
raise an exception
15:11 tenderlove: not 100% sure that's required now
though
15:11 tenderlove: since ko1 thinks we can GC symbols
15:12 tenderlove: (and I'm going to add a DTrace probe on
symbol creation)
15:12 tenderlove: basically, we're tired of playing "whack a
mole" and I'm looking for solutions
15:12 zenspider: I suggested: Symbol.ephemeral { ...symbols
created here don't go in symbol tree... }
15:12 enebo: use string
15:12 marcandre: Is there a theoretical reason that would
prevent us from garbage collecting Symbols?
15:12 Alex_Gaynor: id2sym I think?
15:12 _ko1: enebo++
15:13 tenderlove: enebo: ya, I'm in the slooooooowwwwwww
process of finding all the places we do symbol
conversion
15:13 tenderlove: and changing to string
15:13 tenderlove: (there's no technical reason we're using
symbols anywhere in Rails AFAIK)
15:13 Alex_Gaynor: Sorry, _id2ref
15:13 tenderlove: are hash values on symbols cached?
15:13 Alex_Gaynor: Besides that it's just a matter of using a
weakreference to GC symbols.
15:13 zenspider: speed of key lookups isn't a technical
reason?
15:14 _ko1: marcandre: for MRI, it is implementation's
limitation.
15:14 jballanc: could key lookups with frozen strings emulate
using symbols?
15:14 marcandre: _ko1: which could be, with some work (maybe
much work) overcome, right?
15:15 tenderlove: jballanc: I think if hashes on frozen
strings were cached, yes
15:15 _ko1: marcandre: I wrote in Mailing list.
15:15 marcandre: Isn't GC of symbols the safest route? I mean
maybe Rails can insure that it's ok everywhere, but I
think many apps & libs are using tosym
15:16 zenspider: lisp has (unintern sym) seems like we could
benefit from that
15:16 zenspider: we need to move on
15:16 zenspider: topic: Should YAML.load be the safe version
by default? (marcandre)
15:16 marcandre: The quesiton on my mind is: should the
default deserialization method YAML.load be safe? The
downside is that this can create an incompatibility.
That is also an upside, in the sense that in many cases
where it does, it would force the question "do you want
to unserialize anything, or just some tags, etc..." The
other upside, of course, is to make safe a lot of code
that might not be.
15:16 mame0: long! :-)
15:17 Alex_Gaynor: Yes, and the name for the other message
should not be parse(), as I believe JSON uses, it
should be load and danger_load, or eval_load, or
something very obvious
15:17 tenderlove: no, it shouldn't be safe by default. Same
as Marshal.load
15:17 n0kada-freenode is now known as n0kada
15:18 marcandre: YAML.load! was suggested for unsafe
version
15:18 emboss: load and load! ?
15:18 tenderlove: JSON.load is unsafe
15:18 enebo: Yes!
15:18 _ko1: are there any app depends on denger load?
15:18 tenderlove: _ko1: Rails
15:18 enebo: Name should imply danger or power
15:18 _ko1: tenderlove: wow...
15:18 tenderlove: database configs
15:18 tenderlove: fixtures
15:18 tenderlove: serialized columns
15:19 marcandre: If YAML.load should be safe, say in next
minor, and YAML.load! would be the current unsafe
version, than a minimal migration path would be to
alias YAML.load! today. I know it was judged too late
to add a warning to YAML.load. What about just an
alias? This would give plenty of time for libraries
that want to to call load! if available, otherwise
load, if they decide they should use the "unsafe"
15:19 marcandre: version. Rails 4.0.0, and update releases
for 3.2 could change their code today. Anyone upgrading
Ruby to next minor (say in one year) would not suffer
any incompatibility, assuming they also have
upgradedRails at some point in in that year.
15:19 akr: deep copy using Marshal,
Marshal.load(Marshal.dump(obj)), is sane. Rename
Marshal.load to Marshal.unsafe_load is not fine.
15:19 enebo: Is YAML.eval an insane name…it implies
evaluation
15:19 marcandre: Let's focus on YAML for now.
15:19 tenderlove: marcandre: if we neuter YAML, why bother
using it?
15:19 tenderlove: just use JSON
15:20 marcandre: There will still be YAML.load!
15:20 marcandre: The important thing in my mind is the
default
15:20 marcandre: Just to improve the odds that people using
the unsafe vrsion know that they are doing it
15:21 enebo: default should be tame and the non-tame should
be obvious but then again YAML is not obvious from this
perspective. Many people probably still don't know
about !ruby and thel ike.
15:21 marcandre: agreed.
15:21 tenderlove: enebo: ruby objects aren't the only objects
to be feared
15:21 enebo: tenderlove: no indeed
15:21 zenspider: I think this is a false sense of security.
libraries need to be audited. pretending they're safe
because we neuter yaml encourages ignorance
15:22 marcandre: If we agree on YAML.load and YAML.load!, we
can create an alias in 2.0.0. I don't see the
downside.
15:22 enebo: just pointing out YAML has surprises most people
don't understand
15:22 tenderlove: YAML is a human readable Marshal
15:22 marcandre: YAML can also be seen as a powerful
JSON...
15:22 zenspider: we should move on... but I suspect this
topic is our most egregious one
15:22 enebo: zenspider: will we have a summary near end of
hour?
15:23 zenspider: enebo: try to, yeah
15:23 enebo: ok
15:23 tenderlove: marcandre: our embedded JSON has the same
problem
15:23 zenspider: we'll also have an open question section and
can revisit
15:23 tenderlove: JSON.load is dangerous
15:23 marcandre: IMO, that's even more troubling.
15:23 zenspider: topic: Digest::HMAC? Abandon it or make it
non-experimental? (emboss)
15:23 zenspider:
https://github.com/ruby/ruby/blob/eb4ae6bc542cdec0ade408c2f5ddfebba227d30f/ext/digest/lib/digest/hmac.rb#L13
15:23 mame0: I'm neutral for adding load!, but it first
requires matz's approval.
15:23 mame0: oops, sorry
15:23 emboss: should be quick: there is Digest::HMAC ? Keep
it or throw it out?
15:24 emboss: if we keep it, we should review it and remove
the warning
15:24 jballanc: is there an argument not to keep it in?
15:24 tenderlove: jballanc: the warning?
15:25 zenspider: just did a blame. that warning is 2.5 years
old
15:25 eregon_ is now known as eregon
15:25 akr_: Who added the warning?
15:25 emboss: it's duplicate functionality with
OpenSSL::HMAC, although probably not everybody has the
OpenSSL extension
15:25 akr_: knu?
15:25 zenspider: akr_: knu
15:25 tenderlove: emboss: probably should just ping knu
15:25 tenderlove: he's pretty responsive
15:25 emboss: ok, will do!
15:26 zenspider: topic: Get impressions on how to implement
"erasing a password from memory" (emboss)
15:26 tenderlove: emboss: he's @knu on twitter
15:26 zenspider: https://bugs.ruby-lang.org/issues/5741
15:26 emboss: ok, the problem is I'd really love to have
something that allows to clear a string completely in
memory.
15:27 emboss: use case is: web app receives a submitted
password.
15:27 zenspider: ROT13!! :P
15:27 emboss: you'd bcrypt it or something and feel safe
afterwards. but the actual string stays in
memory...
15:27 kosaki2: it seems to have a long discusstion. I suggest
you make a summarize for getting matz approval.
15:27 jballanc: is it sufficient to clear the string? or do
we need control to overwrite explicitly?
15:27 zenspider: emboss: is this just a GC change? or
something else?
15:27 emboss: lower-level languages allow to overwrite the
memory, and neglecting to do so often results in CVEs
or similar.
15:28 tenderlove: clearing the string may not work since
char* could be shared
15:28 emboss: it's complicated, copying gc could potentially
proliferate the string to many places. I'm not really
sure how to approach it...
15:28 enebo: yeah COW is bigger issue for MRI I think
15:28 emboss: I guess it'd be easier in JRuby as the String
class allows it already?
15:29 enebo: JRuby shares same byte array so we can implement
a zeroout pretty easily
15:29 mame0: I guess that most people cannot use such a
feature properly
15:29 enebo: JRuby implements strings using a byte array
essentially
15:29 akr_: strings are concateneted everywhere. So it's
difficult to erase password derived strings.
15:29 mame0: do you have a plan to use it in some frameworks,
such as rails?
15:29 emboss: i could write an extension, but it's worthless,
because you'd have to replace every usage of
String...
15:29 enebo: and we cache a string but yeah Java Strings can
do it too
15:29 emboss: I think the only way to get people using it is
by adding it to the Ruby String class :(
15:30 tenderlove: this problem sounds hard
15:30 ko1: tenderlove: ++
15:30 kosaki2: personally I like this feature (if anyone
propose a good name)
15:31 emboss: i guess it is, not expecting an answer anyway.
Just wanted to bring it up, maybe somebody has a good
idea eventually.
15:31 akr: For example, net/http send HTTP basic
authentication base64-encoded password. It is
difficult to erase the base64 encoded string from
outside of net/http.
15:31 tenderlove: I think it's a good feature too, but very
hard
15:31 mame0: what does "hard" means?
15:31 tenderlove: also if you read a password in from the
socket, (http post or something) that creates a
string
15:31 tenderlove: mame0: 難しい
15:31 enebo: Can IO add it? and only get secure string type
form an IO operation?
15:32 emboss: tenderlove: yes, trying to avoid string is
almost impossible
15:32 mame0: i know the word itself :-)
15:32 tenderlove: hehehe
15:32 tenderlove: mame0: too many points where strings are
created
15:32 enebo: That type will not COW but will pretend it is a
string and have a good erage and not enter
ObjectSpace?
15:32 mame0: ah i see
15:32 zenspider: time... we'll take it to the ticket url
above
15:32 zenspider: topic: prepend and ancestors,
instance_method, etc... (#7836, #7842, #7844)
15:33 marcandre: I'm worried by the current behavior of
Module.prepend (#7836, #7842, #7844)
15:33 zenspider: https://bugs.ruby-lang.org/issues/7836
15:33 marcandre: Cab we can fix it before releasing 2.0.0? I
hope so!
15:33 marcandre: I was also wondering if other
implementations had tackled Module.prepend, what they
thought of the questions raised by those issues.
15:33 zenspider: https://bugs.ruby-lang.org/issues/7842
15:33 emboss: enebo: wouldn't this still require to replace
Strings in many places?
15:33 zenspider: https://bugs.ruby-lang.org/issues/7844
15:33 enebo: emboss: yeah you would have to rewrite
everything in terms of it and it would be fragile
15:33 ko1: mame0: how about it?
15:34 mame0: I created the tickets for showing my intention
that it should be fix in next minor :-)
15:34 kosaki2: It seems too late for 2.0.
15:34 mame0: The alternative is making Module#prepend as
experimental
15:34 mame0: in 2.0.0
15:34 enebo: Can anyone use a feature if the semantics change
between minor releases?
15:34 zenspider: (yes please)
15:35 enebo: I suppose prepend will work the same so long as
it is not complex usage but anything involving modules
can quickly get complicated
15:36 enebo: taps the mic…is this thing on
15:36 tenderlove: lol
15:36 tenderlove: I haven't investigated prepend at all
15:36 tenderlove: orz
15:36 marcandre: enebo: so JRuby hasn't really looked at it,
then?
15:36 zenspider: apparently I'm going fast on topic movement.
hit me up if you think I should revisit something
15:36 zenspider: we've got one more topic + open q's +
wrapup
15:37 enebo: marcandre: tbh when I looked at those issues I
realized prepend did not work as I expected
15:37 zenspider: I agree
15:38 jballanc: enebo: I agree, is there a reason "prepend"
shouldn't just act locally?
15:38 marcandre: Yes!
15:38 n0kada: now trying to fix prepend issues
15:38 enebo: jballanc: I htought it was local to the
hierearchy of where it was added
15:38 marcandre: At least I see prepend as the old
alias_method_chain
15:38 mame0: n0kada: thx, but 2.0.0-p0 will not include the
fixes
15:38 jballanc: yes, that was my understanding too
15:39 marcandre: So it should have a similar effect, i.e. non
local
15:39 mame0: 2.0.0-pXXX may include, but it is up to
@nagachika
15:39 zenspider: can we get it marked as experimental?
15:39 zenspider: that seems the safest way?
15:39 marcandre: or as buggy :-)
15:39 n0kada: they will be KNOWNBUGS
15:39 marcandre: ++
15:39 kosaki2: experimental ++
15:39 mame0: knownbugs++
15:40 marcandre: KNOWNBUGS++
15:40 zenspider: both++ ?
15:40 marcandre: If we can at least agree on what it is
supposed to be...
15:40 akr: KNOWNBUGS += 1
15:40 tenderlove: enebo: ?
15:40 zenspider: enebo, chime in pls
15:40 enebo: I think experimental
15:40 n0kada: new features often have corner case bugs
15:40 marcandre: So basically use it, and watch out about too
complex scenarios...
15:40 enebo: 7844 makes it sound like classes will do some
transitive graph resolution
15:41 mame0: there will be no end if we mark all features as
experimental just because it has known bugs
15:41 enebo: and I thought it was much much simpler than
that
15:41 mame0: ruby will be marked as experimental
15:41 tenderlove: I agree with mame0. All features will end
up experimental.
15:41 jballanc: it seems that prepend used with classes is
fairly well understood?
15:41 enebo: I could cope with NKOWNBUGS knowing that this
conversation will continue
15:42 enebo: My only fear is people will run with the feature
and then get angry when it changes
15:42 tenderlove: enebo: hopefully listing it in KNOWNBUGS
would help alleviate that
15:42 enebo: tenderlove: yeah possibly
15:42 zenspider: I think the problem is that there is no
clearly defined specification.
15:42 zenspider: ok. we should move on
15:42 zenspider: topic: invite security ML members,
especially non-MRI implementers
15:42 zenspider: I don't know who's topic this is
15:43 zenspider: I for one welcome my new security
overlords
15:43 tenderlove: in the name of security, do X!
15:43 tenderlove: who added this?
15:44 tenderlove: did the wiki get hacked?
15:44 enebo: why not? apparently there is not too big a
problem with too many people talking :)
15:44 enebo: Anonymous!
15:44 zenspider: enebo: YOU SHUT IT :P
15:44 enebo: zips it
15:44 zenspider: was this added before martin got added to
core?
15:44 tenderlove: we've added emboss to the rails sec
team
15:44 tenderlove: fwiw
15:44 emboss: i have nothing to do with it :)
15:45 tenderlove: emboss: are you on ruby sec team?
15:45 zenspider: emboss: no... I'm saying I think it came up
because we knew we needed you :)
15:45 emboss: tenderlove: yes
15:45 mame0:
https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20130215/diff?version=14&version_from=13&commit=View+differences
15:45 emboss: zenspider: thx ;)
15:46 zenspider: anyone else we should add?
nominations?
15:46 tenderlove: unak!
15:46 mame0: usa-san enjoys holiday
15:46 tenderlove: hahahaha
15:46 tenderlove: he added to the list
15:46 tenderlove: but didn't show up
15:46 tenderlove: very smart move
15:46 zenspider: haha
15:46 zenspider: ok.
15:46 zenspider: should we revisit any topics? or open to
questions?
15:46 zenspider: sorry I went so fast... sorta
15:47 marcandre: I propose that Matz be here next time
;-)
15:47 enebo: I think we should assemble some Matz questions
if we can out of this
15:48 tenderlove: ya
15:48 tenderlove: papa matz
15:48 tenderlove: Y U NO ATTEND
15:48 zenspider: yaml, symbols, hmac ejection...
15:48 zenspider: I'm not sure the yaml one has a ticket, just
ruby-core thread
15:48 enebo: ko1: Who can we ask about GC'ing symbols in
MRI?
15:48 enebo: :)
15:48 zenspider: tenderlove: pls make sure there is a ticket
and assign to matz for weighin
15:48 jballanc: Just wanted to point to a ticket I had
created re: binding semantics discussion from last
meeting -- http://bugs.ruby-lang.org/issues/7747
15:48 _ko1: enebo: nobu
15:48 tenderlove: ><
15:49 n0kada: ko1: who's it
15:49 jballanc: ...would love any comments/feedback
15:49 zenspider: NOW he shows up :P
15:49 tenderlove: 50min late
15:49 enebo: get him
15:49 mame0: hello
15:49 tenderlove: haha
15:49 matz: I am sorry
15:50 zenspider: man.... all this binding / prepend /
refinements stuff... makes me feel old
15:50 eregon: Was late to the party, but I'm thinking
changing YAML.load is a bad idea, there will always be
"dangerous" methods, which are mostly features. And
"load" is like Kernel#load which is hopefully known to
be quite powerful. So I'm in favor of something like
safe_load and documenting well dangerous methods
15:50 zenspider: I want my old ruby back
15:50 zenspider: GET OFF MY LAWN
15:50 eregon: yeah sounds like it went from a tree to a
complex multi graph
15:51 marcandre: It can still be a tree!
15:51 zenspider: that's a good point about Kernel#load. I
hadn't made that connection
15:51 eregon: as zenspider said earlier, is there a clear
spec to wrap thoughts around it?
15:51 jballanc: personally, I would love it if Ruby's
superclass/module lookup semantics could be implemented
in Ruby, if only for reference purposes
15:52 zenspider: 8 minutes left
15:52 tenderlove:
https://bugs.ruby-lang.org/issues/7780
15:52 tenderlove: presumably
15:52 kosaki2: i dislike to use 'safe' for method name. It is
too unclear.
15:53 zenspider: any more about symbols?
15:54 akr_: load_anyobj
15:54 akr_: just an idea.
15:54 enebo: I think we should use most likely name for safe
name that a new programmer would think they should
use
15:55 enebo: which strikes me is load
15:55 mame0: ruby <- dangerous
15:55 enebo: mame0: Danger is its middle name
15:55 n0kada: red is the sign for danger
15:55 zenspider: hah
15:56 zenspider: 5 minutes
15:56 zenspider: 4
15:56 zenspider: should we summarize? we haven't had time in
any of our previous meetings
15:56 enebo: My only argument for safer default is continued
security issues because new programmers don't
understand Yaml is not a better syntax for XML
15:56 zenspider: I think as long as the wiki gets updated
with links to the issue tracker we don't really need a
summary here
15:56 enebo: not just a
15:56 ko1: version number issue?
15:56 zenspider: tenderlove has a ticket for symbols... jsut
needs to update the wiki
15:57 tenderlove: enebo: we can add documentation
15:57 marcandre: Ideally, Ruby would be dangerous for the
right reasons. If you want to load code, that has to
be dangerous, by definition. If you want to read JSON,
it shouldn't be, at least by default. I'll stop
repeating myself, promised!
15:57 zenspider: _ko1: thank you. yes.
15:57 enebo: tenderlove: at a minimum
15:57 tenderlove: I don't understand why we're treating it
differently than Marshal
15:57 zenspider: marcandre: that still seems like a "we need
to audit our libraries" issue more than a marshalling
issue
15:57 tenderlove: because it's human readable, so you assume
safe?
15:58 zenspider: do we need a ticket for the versioning
question?
15:58 Alex_Gaynor has left ()
15:58 zenspider: who's was that?
15:58 enebo: Substitute YAML for COM and Ruby for Windows…not
try this all again
15:58 enebo: not=now
15:58 zenspider: enebo?
15:58 marcandre: Because it's human readable and used 99.9%
of cases for basic types.
15:58 enebo: zenspider: I did not add that
15:58 zenspider: hrm...
15:58 tenderlove: marcandre: site your sources :P
15:58 tenderlove: cite
15:59 marcandre: 85% of statistics are made up :-)
15:59 zenspider: I heard it is up to 89%
15:59 zenspider: versioning was drbrain... who isn't actually
here
15:59 zenspider: so that can be tabled until next
meeting
15:59 mame0: marcandre suggested "load" for safe and "load!"
for dangerous in future, and adding an alias "load!"
to "load" as a first step in 2.0.0.
15:59 mame0: matz: what do you think?
16:00 zenspider: ok. let's get the wiki updated with issue
links and we're pretty much done
16:01 matz: I think marcandre's idea is good, but not for
2.0.0 coming in 9 days
16:01 marcandre: Of course, for 2.0.0 would only be adding
the alias
16:02 mame0: indeed. you are good release manager
16:02 ko1: mame0: will you write known bug documents?
16:02 _ko1: about prepend
16:03 mame0: where should we write?
16:03 mame0: please contribute!
16:03 matz: If I were mame0, I'd add load! (or whatever)
after 2.0.0
16:03 ko1: yabuhebi (backfire) :(
16:04 mame0: agreed, thx
16:04 enebo: matz: but an alias from load! to load seems
fairly harmless?
16:04 tenderlove: enebo: there's currently no safe_load in
trunk
16:05 zenspider: the alias does seem easy to sneak in for
2
16:05 enebo: tenderlove: The idea is to promote this for the
upcoming change assuming making load safe if the
desired goal
16:06 tenderlove: sounds like we have many volunteers for
YAML maintenance ;)
16:06 _ko1: meeting is up?
16:06 zenspider: _ko1: yes, meeting is done
16:06 enebo: tenderlove: my patch: alias :load! :load
16:06 _ko1: zenspider: thanks
16:06 zenspider: thanks everyone
16:07 marcandre: thanks
16:07 mame0: thanks

Post Meeting Discussion

16:07 ko1: matz: do you think about next version number? /
release date?
16:07 matz_: Even though in Ruby "!" means "dangerous", bang
methods in standard library uses it to show side
effect.
16:07 ko1: next of 2.0.0
16:07 enebo: matz: yeah true, but many people now use it to
mean danger as well outside of core
16:07 jballanc: thanks all
16:08 tenderlove: that seems legitimate. The side effect of
loading an arbitrary object is "can eval code"
;-)
16:08 ko1: tenderlove: addd while(1);
16:08 matz: I understand. @enebo
16:08 enebo: matz_: we need to add unicode hazard symbol
perhaps
16:08 tenderlove: hahaha
16:08 matz_: @enebo indeed. LoL
16:09 zenspider has left ("ERC Version 5.3 (IRC client for
Emacs)")
16:10 kosaki2_: !
16:10 tenderlove: kosaki2_: yes
16:10 kosaki2_: usa-san said me the meanings of topic "invite
security ML members, especially non-MRI
implementers"
16:10 kosaki2_: He want to invite non MRI implementers to
ruby security ML.
16:11 kosaki2_: I fully agree it.
16:11 mame0: who will we invite?
16:11 kosaki2_: I think just current attendee.
16:12 ko1: (hide)
16:12 tenderlove: kosaki2: who does he want?
16:12 kosaki2_: If someone interested
16:12 tenderlove: I nominate ko1
16:12 mame0: っ _ko1
16:12 tenderlove: hahaha
16:12 _ko1: jruby and rubinius guys
16:12 tenderlove: I think Charles is on the ruby sec
team
16:12 tenderlove: I don't know about rbx guys
16:12 kosaki2: I think jruby guys already subscribed
16:12 mame0: headius is already the member
16:12 mame0: oops
16:13 ko1: sorry, i don't know sec ml completely
16:13 mame0: you should join
16:13 mame0: then
16:13 kosaki2: mame++
16:13 tenderlove: hahaahahahah
16:14 kosaki2_: so plz contact sec ml if other implementers
are interest to subscribe sec ml.
16:14 kosaki2_: done
16:14 tenderlove: I'm already on Rails sec team, so I can't
join
16:14 tenderlove: hahaha
16:14 tenderlove: okay
16:14 ko1: matz: (repeat) do you have any thought about
next (of 2.0.0) version number? / release date?
16:14 mame0: the next is 2.1.0, okay?
16:15 ko1: matz: i want to ask current rough idea.
16:15 emboss: tenderlove: are the other rails sec guys on
ruby's sec list? I guess it couldn't hurt to know about
Ruby vulns even from a Rails perspective. Much overlap
anyway.
16:15 matz_: I think we are going to move on 2.1
development.
16:15 tenderlove: no
16:16 ko1: matz: release date?
16:16 tenderlove: emboss: you're on both, so we will rely on
you
16:16 mame0: just an idea: 2.1.0 around the Xmas at this
year
16:16 matz_: And we will release 2.0.1 as a maintenance
version
16:16 emboss: haha, fair enough ;)
16:16 mame0: too early?
16:17 matz_: mame0: sounds fine
16:17 mame0: great
16:17 ko1: mame0: you continue 2.1.0 release manager ?
16:17 _ko1: it sounds great
16:18 mame0: if no one is against it
16:19 _ko1: thanks matz, mame.
16:19 _ko1: m&m
16:19 mame0: but I'm busier and busier than before
16:19 mame0: I'm not sure if I have enough time
16:19 emboss: _ko1: m&m -> eminem ;)
16:20 jballanc has left ()
16:21 mame0: is there no topic?
16:21 mame0: the meeting is over, but we still get matz
16:22 _ko1: already finished.
16:22 mame0: we should exploit the chance
16:22 kosaki2: exploit :)
16:28 ko1: > 09:15 matz > And we will release 2.0.1 as
a maintenance version
16:28 ko1: no 2.0.0-pXXX version?
16:28 mame0: I'm not interested in 2.0.1 :-)
16:30 matz: ko1: it depends on bugs we will see
16:30 _ko1: matz: i got it
16:31 mame0: 2.0.0-pXX will be released as before
16:31 mame0: 2.0.1 will be released if needed
16:32 mame0: and we will focus 2.1.0 development towards the
Xmas
16:32 ko1: seems good
16:32 mame0: I'll send announcement after 2.0.0-p0
16:32 _ko1: prepend fix -pXX ?
16:33 akr: We consumes versions more rapidly than 1.x.
single digit restriction may be bigger problem.
16:33 mame0: it is up to @nagachika
16:33 mame0: minor release every year
16:33 mame0: 2.1 -> 2013
16:33 ko1: we have 80 years if we increment minor.
16:33 mame0: 2.2 -> 2014
16:34 mame0: matz's life is so long
16:34 _ko1: we have iPS cells
16:37 mame0: there are only Japanese people
16:38 mame0: they shall now enjoy TGIF
16:38 mame0: jealous
16:38 _ko1: TGIF?
16:38 _ko1: Thank God, It's Friday
16:40 mame0: 2.1.0 should complete refinement
16:40 mame0: hang in there
16:41 _ko1: i bet my 100 JPY coin: we can't wrap up
refinement in this year
16:45 n0kada: Tgif: a drawing tool
16:48 matz: I have leave (in reality)
16:48 matz_: I leave my xchat logged in
16:49 _ko1: thanks matz
16:50 mame0: thank you!