(https://github.com/ruby/resolv/pull/33)
* Implement dohpath SvcParam [RFC 9461]
This patch implements "dohpath" SvcParam proposed in
[draft-ietf-add-svcb-dns-08]. This parameter specifies a URI template
for the :path used in DNS-over-HTTPS requests.
"dohpath" is employed by [DDR], also a to-be-published Proposed Standard
that specifies how to upgrade DNS transport to a more secure one, i.d.,
DNS-over-TLS or DNS-over-HTTPS. DDR is deployed in the public DNS
resolvers including Cloudflare DNS, Google Public DNS, and Quad9.
[RFC 9461]: https://datatracker.ietf.org/doc/rfc9461/
[DDR]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/https://github.com/ruby/resolv/commit/da9c023539
Co-authored-by: Sorah Fukumori <her@sorah.jp>
(https://github.com/ruby/resolv/pull/32)
* Add MessageDecoder#get_list
This method repeats yielding until all the data upto the current limit
is consumed, and then returns an Array containig the block results.
* Implement SVCB and HTTPS RRs [RFC 9460]
> This patch implements SVCB and HTTPS resource record types defined in
> [RFC 9460].
>
> The RR types are now supported by many server implementations including
> BIND, unbound, PowerDNS, and Knot DNS. Major browsers such as Chrome,
> Edge, and Safari have started to query HTTPS records, with the records
> gradually adopted by websites. Also, SVCB is actually deployed in the
> public DNS resolvers such as Cloudflare DNS and Google Public DNS for
> [DDR].
>
> With such wide adoption, we have plenty of real-world use cases, and
> it is unlikely the wire format will change further in an incompatible
> way. It is time to implement them in the client libraries!
>
> # Rationale for proposed API
>
> ## `Resolv::DNS::Resource::IN::ServiceBinding`
>
> This is an abstract class for SVCB-compatible RR types.
> SVCB-compatible RR types, as defined in the Draft, shares the wire
> format and the semantics of their RDATA fields with SVCB to allow
> implementations to share the processing of these RR types. So we do
> so.
>
> The interface of this class is straightforward: It has three
> attributes `priority`, `target`, and `params`, which correspond the
> RDATA fields SvcPriority, TargetName, and SvcParams, resp.
>
> SVCB RR type is defined specifically within IN class. Thus, this
> class is placed in the `Resolv::DNS::Resource::IN` namespace.
>
> ## `Resolv::DNS::Resource::IN::SVCB`, `Resolv::DNS::Resource::IN::HTTPS`
>
> Just inherits ServiceBinding class.
>
> ## `Resolv::DNS::SvcParam`
>
> This class represents a pair of a SvcParamKey and a SvcParamValue.
> Aligned with the design of `Resolv::DNS::Resource`, each SvcParamKey
> has its own subclass of `Resolv::DNS::SvcParam`.
>
> ## `Resolv::DNS::SvcParam::Generic`
>
> This is an abstract class representing a SvcParamKey that is unknown
> to this library. `Generic.create(key)` dynamically defines its
> subclass for specific `key`. E.g., `Generic.create(667)` will define
> `Generic::Key667`.
>
> This class holds SvcParamValue in its wire format.
>
> SvcParam with an unknown SvcParamKey will be decoded as a subclass of
> this class. Also, users of this library can generate a non-supported
> SvcParam if they know its wire format.
>
> ## `Resolv::DNS::SvcParams`
>
> This is conceptually a set of `SvcParam`s, whose elements have the
> unique SvcParamKeys. It behaves like a set, and for convenience
> provides indexing by SvcParamKey.
>
> - `#initialize(params)` takes an Enumerable of `SvcParam`s as the
> initial content. If it contains `SvcParam`s with the duplicate key,
> the one that appears last takes precedence.
> - `#[](key)` fetches the `SvcParam` with the given key. The key can be
> specified by its name (e.g., `:alpn`) or number (e.g., `1`).
> - `#add(param)` adds a `SvcParam` to the set. If the set already has a
> `SvcParam` with the same key, it will be replaced.
> - `#delete(key)` deletes a `SvcParam` by its key and returns it. The key
> can be specified by its name or number.
* Update comments referring to draft-ietf-dnsop-svcb-https-12
Published as RFC 9460. https://datatracker.ietf.org/doc/rfc9460/
[draft-ietf-dnsop-svcb-https-12]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/12/
[RFC 9460]: https://datatracker.ietf.org/doc/rfc9460/
[DDR]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/https://github.com/ruby/resolv/commit/b3ced7f039
(https://github.com/ruby/irb/pull/768)
When user enters irb:rdbg session, they don't get the same hint that the
`debug` gem provides, like
```
(rdbg) n # next command
```
This means that users may accidentally execute commands when they want to
retrieve the value of a variable.
So this commit adds a Reline output modifier to add a simiar hint:
```
irb:rdbg(main):002> n # debug command
```
It is not exactly the same as `debug`'s because in this case the importance
is to help users distinguish between value evaluation and debugger command
execution.
https://github.com/ruby/irb/commit/fdf24de851
If a platform specific variant would not match the current Ruby, we would still be
considering it compatible with the initial resolution and adding its
platform to the lockfile, but we would later fail to materialize it for
installation due to not really being compatible.
Fix is to only add platforms for variants that are also compatible with
current Ruby and RubyGems versions.
https://github.com/rubygems/rubygems/commit/75d1290843
* The same order as in source code.
* CallOrWriteNode, CallOperatorWriteNode, CallAndWriteNode already have
the correct order so it was also inconsistent with them.
https://github.com/ruby/prism/commit/4434e4bc22
(https://github.com/ruby/resolv/pull/25)
* IPv6: update to_s method to be RFC5952 compliant
I noticed that the resolv library does not honour RFC 5952 Section 4.2.2.
in relation to textural representation of ipv6 addresses:
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.
Fixes https://github.com/ruby/resolv/pull/24https://github.com/ruby/resolv/commit/5efcd6ed70
Co-authored-by: Sorah Fukumori <sora134@gmail.com>
(https://github.com/ruby/irb/pull/771)
I propose introducing the capability to set the IRB completion kinds via an environment variable, specifically `IRB_COMPLETOR=type`.
This feature aims to enhance the Rails console experience by allowing Rails users to specify their preferred completion more conveniently.
Currently, when using the Rails console, there's no straightforward way to globally set the type completion across a Rails application repository.
It's possible to configure this setting by placing a `.irbrc` file at the project root. However, using a .irbrc file is not ideal as it allows for broad configurations and can potentially affect the production environment.
My suggestion focuses on allowing users to set the completion to 'type' in a minimal.
This enhancement would be particularly beneficial for teams writing RBS in their Rails applications.
This type completer, integrated with RBS, would enhance completion accuracy, improving the Rails console experience.
https://github.com/ruby/irb/commit/032f6da25f
Calling `tokens_to_s` gets an error if `token_stream` is nil:
```
undefined method `compact' for nil:NilClass (NoMethodError)
```
So, fall back to an empty array if `@token_stream` is nil.
https://github.com/ruby/rdoc/commit/452e4a2600
Gem::RemoteFetcher uses Gem::Request, which adds the RubyGems UA.
Gem::RemoteFetcher is used to download gems, as well as the full index.
We would like the bundler UA to be used whenever bundler is making
requests.
This PR also avoids unsafely mutating the headers hash on the shared
`Gem::RemoteFetcher.fetcher` instance, which could cause corruption or
incorrect headers when making parallel requests. Instead, we create one
remote fetcher per rubygems remote, which is similar to the connection
segregation bundler is already doing
https://github.com/rubygems/rubygems/commit/f0e8dacdec
librubyparser was an artifact of the prototype that was initially
named ruby-parser. Instead, this renames it to libprism to be
consistent with the actual name.
https://github.com/ruby/prism/commit/8600b06811
If a Gemfile duplicates a development dependency also defined in a local
gemspec with a different requirement, the requirement in the local
gemspec will be silently ignored.
This surprised me.
I think we should either:
* Make sure both requirements are considered, like it happens for
runtime dependencies (I added a spec to illustrate the current behavior
here).
* Add a warning that the requirement in the gemspec will be ignored.
I think the former is slightly preferable, but it may cause some
bundle's that previously resolve to no longer resolver.
I went with the latter but the more I think about it, the more this
seems like it should behave like the former.
https://github.com/rubygems/rubygems/commit/ad6843972f
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
Instead of storing the delegate in @tmpfile, use __getobj__, since
delegate library already handles dup/clone for that. Copy the
unlinked, mode, and opts instance variables to the returned object
when using dup/clone.
Split the close/unlink finalizer into two finalizers. The close
finalizer always closes when any Tempfile instance is GCed, since
each Tempfile instance uses a separate file descriptor. The unlink
finalizer unlinks only when the original and all duped/cloned
Tempfiles are GCed, since all share the same path.
For Tempfile#open, undefine the close finalizer after closing the
current file, the redefine the close finalizer with the new file.
Fixes [Bug #19441]
https://github.com/ruby/tempfile/commit/dafabf9c7b
Since #6945 the extension dir changed to Gem::BasicSpecification's implementation, we didn't hook that in rubygems_ext.rb. So for universal rubies, we ended up using the universal platform name when installing, but arch replaced platform name when checking. This lead to native extensions can never be correctly installed on universal rubies.
Hook Gem::BasicSpecifications so the behavior is consistent on installing and checking.
https://github.com/rubygems/rubygems/commit/8d699ed096
Right now the `rb_shape_get_next` shape caller need to
first check if there is capacity left, and if not call
`rb_shape_transition_shape_capa` before it can call `rb_shape_get_next`.
And on each of these it needs to checks if we got a TOO_COMPLEX
back.
All this logic is duplicated in the interpreter, YJIT and RJIT.
Instead we can have `rb_shape_get_next` do the capacity transition
when needed. The caller can compare the old and new shapes capacity
to know if resizing is needed. It also can check for TOO_COMPLEX
only once.
(https://github.com/ruby/irb/pull/708)
* Add completor using prism and rbs
* Add TypeCompletion test
* Switchable completors: RegexpCompletor and TypeCompletion::Completor
* Add completion info to irb_info
* Complete reserved words
* Fix [*] (*) {**} and prism's change of KeywordParameterNode
* Fix require, frozen_string_literal
* Drop prism<=0.16.0 support
* Add Completor.last_completion_error for debug report
* Retrieve `self` and `Module.nesting` in more safe way
* Support BasicObject
* Handle lvar and ivar get exception correctly
* Skip ivar reference test of non-self object in ruby < 3.2
* BaseScope to RootScope, move method objects constant under Methods
* Remove unused Splat struct
* Drop deeply nested array/hash type calculation from actual object. Now, calculation depth is 1
* Refactor loading rbs in test, change preload_in_thread not to cache Thread object
* Use new option added in prism 0.17.1 to parse code with localvars
* Add Prism version check and warn when :type completor cannot be enabled
* build_type_completor should skip truffleruby (because endless method definition is not supported)
https://github.com/ruby/irb/commit/1048c7ed7a
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
https://github.com/rubygems/rubygems/commit/4bced7ac73
The combination of `install-dir` and `--user-install` used to be
disabled for no good reason. This even makes problem on Linux
distributions such as Fedora, where `--user-install` is set by default
via operating_system.rb.
The `--install-dir` is already prefered over the `--user-install` by
the implementation, therefore just drop the check.
https://github.com/rubygems/rubygems/commit/313b1c5e76
The main purpose is to put handling of user installation into the same
place as e.g. handling the --build-root option handling. There is no
reason why the --build-root option should not prefix also paths used for
user installation.
Please note that the `util_installer` in
`test_generate_plugins_with_user_install` enforced the `:install_dir`,
which is against what user install is about.
https://github.com/rubygems/rubygems/commit/0b10cb41aa
character attributes
(https://github.com/ruby/reline/pull/552)
* Reine::Face
* fix test_yamatanooroti
* Define singleton methods to make accessors to attributes of a face
* s/display/foreground/
* s/default/default_style/ && s/normal_line/default/ && s/enhanced_line/enhanced/
* fix typo
* FaceConfig.new now takes keyword arguments
* Update lib/reline/face.rb
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Update test/reline/test_face.rb
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Fix to correspond to frozen_string_literal
* Face::FaceConfig -> Face::Config
* ref https://github.com/ruby/reline/pull/552#pullrequestreview-1677282576
* delete unused ivar
* ref https://github.com/ruby/reline/pull/552#discussion_r1358783723
* insert "\e[0m" into all SGR
* tiny fix
* ESSENTIAL_DEFINE_NAMES
ref https://github.com/ruby/reline/pull/552#discussion_r1367722247
* Change to Hash-accessor style
- Reline::Face[:completion_dialog].enhanced ->
Reline::Face[:completion_dialog][:enhanced]
- Reline::Face.configs shows all defined values
* Cache array method call in local variable
* Tests for Face configuration variations
* resolve https://github.com/ruby/reline/pull/552#pullrequestreview-1710938154
* amend to
* check invalid SGR parameter in :style
* The order of define values should be preserved
* Update test/reline/test_face.rb
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Update test/reline/test_face.rb
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Add methods: load_initial_config and reset_to_initial_config. And teardown in tests
* omission in amending "style: :default" to "style: :reset"
* refs https://github.com/ruby/reline/issues/598
* Fix link
* amend method name
* Update lib/reline/face.rb
Co-authored-by: ima1zumi <52617472+ima1zumi@users.noreply.github.com>
---------
https://github.com/ruby/reline/commit/fdc1d3b1e5
Co-authored-by: Stan Lo <stan001212@gmail.com>
Co-authored-by: ima1zumi <52617472+ima1zumi@users.noreply.github.com>
Prior to this commit, KeywordParameterNode included both optional
and required keywords. With this commit, it is split in two, with
`OptionalKeywordParameterNode`s no longer having a value field.
https://github.com/ruby/prism/commit/89084d9af4
Method calls with keyword splat args compile differently than
without since they merge the keyword arg hash with the keyword splat
hash. We know this information at parse time, so can set a flag
which the compiler can use.
https://github.com/ruby/prism/commit/e5f8a9a3cd
We used `Bundler::RubyVersion.system.gem_version` for a long time, but I
changed this to `Gem.ruby_version` at
https://github.com/rubygems/rubygems/commit/94f96439438e. It's unclear why I did that
though since I believe it was unrelated to the fix in there.
Bootboot patches `Bundler::RubyVersion` to customize how Bundler works
with Ruby versions, and that change broke that.
Since it's unclear to me how to achieve what Bootboot is doing with the
current code, and there was no strong reason for the change, let's
restore it for now.
https://github.com/rubygems/rubygems/commit/8ec36c6017
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
https://github.com/rubygems/rubygems/commit/26ceee0e76
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
https://github.com/rubygems/rubygems/commit/86c7084e1c
1. Use the checksum provided by the server if provided: provides security
knowing if the gem you downloaded matches the gem on the server
2. Calculate the checksum from the gem on disk: provides security knowing
if the gem has changed between installs
3. In some cases, neither is possible in which case we don't put anything
in the checksum and we maintain functionality as it is today
Add the checksums to specs in the index if we already have them
Prior to checksums, we didn't lose any information when overwriting specs
in the index with stubs. But now when we overwrite EndpointSpecifications
or RemoteSpecifications with more generic specs, we could lose checksum
info. This manually sets checksum info so we keep it in the index.
https://github.com/rubygems/rubygems/commit/de00a4f153
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
https://github.com/rubygems/rubygems/commit/bde37ca6bf
These are necessary to get the tests passing with LibreSSL 3.8.1+,
which dropped support for TLSv1.0 and TLSv1.1 for security reasons.
This updates the tests to use TLSv1.2 on OpenBSD. This is only
strictly necessary on OpenBSD 7.4+, but it will work fine in previous
versions as well.
https://github.com/ruby/drb/commit/32707b2db5
Currently, you can install multiple versions of the same gem just fine:
```
$ gem install simplecov:0.19.0 simplecov:0.22.0
Fetching simplecov-0.19.0.gem
Successfully installed simplecov-0.19.0
Parsing documentation for simplecov-0.19.0
Installing ri documentation for simplecov-0.19.0
Done installing documentation for simplecov after 0 seconds
Fetching simplecov-0.22.0.gem
Successfully installed simplecov-0.22.0
Parsing documentation for simplecov-0.22.0
Installing ri documentation for simplecov-0.22.0
Done installing documentation for simplecov after 0 seconds
2 gems installed
```
But to uninstall both of them, you need to run the equivalent uninstall
command twice:
```
~$ gem uninstall simplecov:0.19.0 simplecov:0.22.0
Successfully uninstalled simplecov-0.22.0
~$ gem uninstall simplecov:0.19.0 simplecov:0.22.0
Gem 'simplecov' is not installed
Successfully uninstalled simplecov-0.19.0
```
This resolves that problem by using the gem's full name (which includes
the version) when tracking which ones have already been uninstalled so
when it gets to the second version listed it doesn't think it was
already uninstalled.
https://github.com/rubygems/rubygems/commit/d96101b753
The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
https://github.com/rubygems/rubygems/commit/1d501ae8ea
I couldn't find a cross-platform way to check "can I create this directory?"
So I removed that, and went back to the original simpler logic of
"if the directory is writable, use it."
https://github.com/rubygems/rubygems/commit/3aa86a56db
The extconf.rb in mysql2 gem repeats `dir_config('mysql')`, without
and with the default path. The third call returns the former results
even with the default path. Since it does not check the results of
the third call, that `nil` is passed to `find_library` as a path, and
fails with `NoMethodError`.