On Fri, 14 Jan 2022 at 15:12, Sam Ruby <ru...@intertwingly.net> wrote: > > On Fri, Jan 14, 2022 at 9:52 AM sebb <seb...@gmail.com> wrote: > > > > On Fri, 14 Jan 2022 at 14:04, Sam Ruby <ru...@intertwingly.net> wrote: > > > > > > On Fri, Jan 14, 2022 at 8:30 AM sebb <seb...@gmail.com> wrote: > > > > > > > > I'm wondering whether we should pin major version numbers of Gems. > > > > > > > > Combined with a regular job to look for outdated Gems, > > > > I think that would have given us advance warning. > > > > > > I gather that the gem in question that was updated was psych. We > > > don't directly reference it in our Gemfile. > > > > It also affected yaml, but we don't seem to reference that either > > Yaml is part of the Ruby core runtime library. It does not provide a > safe_load method. But all classes in Ruby are "open". > > Looking at Gemfile.lock for the board agenda tool, rdoc -- of all > things -- pulls in psych. It specifies ">= 4.0.0". > > Here is the history for psych: https://rubygems.org/gems/psych > > > > There are two major strategies for dealing with dependencies: > > > > > > * The one we currently deploy aggressively pulls fixes, which has the > > > benefit of being automatic, and ensures we are up to date > > > (particularly with security fixes). > > > > But does it need to pull in changes to major versions? > > Could we not pin the major versions but allow minor updates? > > It looks to me like this was released as a minor version. > > > > * The other is to check in Gemfile.lock files and only run in > > > production what has been tested locally. This would request > > > frequently updating Gemfile.lock files for each whimsy application > > > locally and checking in the results. > > > > Is there any way to get advance notification of which gems have updates? > > And which have security implications? > > That would be closer to the way that other ecosystems such as Java work. > > > > Or at least if we had notification when there has been a change to a > > major version of a Gem that would alert us to possible > > incompatibilities. > > In summary, we are using an API that is not part of the documented > interface for YAML, and might be considered "private" to psych.
YAML says it is an alias for Psych, for which safe_load is documented: https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load The above version is what we used originally It looks like it changed in https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load > It changed in a minor version in a way that broke our code. > > I don't know of any notification mechanism that would help with that > combination. > > - Sam Ruby > > > > > > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby <ru...@intertwingly.net> wrote: > > > > > > > > > > I was debugging the same thing, and came to the same conclusion. By > > > > > the way this affects the roster tool as well as the board agenda. > > > > > > > > > > - Sam Ruby > > > > > > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > Looks like the API for YAML.safe_load has changed. It now requires > > > > > > named > > > > > > parameters. > > > > > > > > ...
