(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
Previously, because gc_update_object_references() did not update the
VALUEs in the too_complex ivar st_table for T_CLASS and T_MODULE
objects, GC compaction could finish with corrupted objects.
- start with `klass`, not too_complex
- GC incremental step marks `klass` and its ivars
- ruby code makes `klass` too_complex
- GC compaction runs and move `klass` ivars, but because `klass` is
too_complex, its ivars are not updated by gc_update_object_references(),
leaving T_NONE or T_MOVED objects in the ivar table.
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
Marking both keys and values versus marking just values is an important
distinction, but previously, gc_update_tbl_refs() and gc_update_table_refs()
had names that were too similar.
The st_table storing ivars for too_complex T_OBJECTs have IDs as keys,
but we were marking the IDs unnecessary previously, maybe due to the
confusing naming.
* YJIT: record num_send_cfunc stat
Also report num_send_known_cfunc as percentage of num_send_cfunc
* Rename num_send_known_cfunc => num_send_cfunc_inline
Name seems more descriptive of what we do with out custom codegen
Previously, it tripped the assert about too_complex in
ROBJECT_IV_CAPACITY(). This fixes double faults for some crashes and
helps with use during development.
When evacuating generic instance variables, the instance variables exist
in both the array and the ST table. We need to ensure it has switched
to the ST table before performing any operations that can trigger GC
compaction.
We've seen occasional CI failures on i686 in this codepath:
```
[BUG] vm_setivar_slowpath: didn't find ivar @verify_depth in shape
```
Generic ivars are very complex to get right, but also quite rare.
I don't see a good reason to take the risk to give them an optimized
path here, when the much more common T_CLASS/T_MODULE don't have one.
Having an optimization here means duplicating the fairly brittle
logic, which is a recipe for bugs, and I don't think it's worth
it in such case.
* [win32] fix compilation for windows-arm64
Credits to MSYS2 Ruby package using this patch.
* [win32] nm use full options
Fix compilation error when using MSYS2 environment.
Credits to MSYS2 Ruby package using this patch.
* [win32] detect llvm-windres (used for windows-arm64)
When adding preprocessor option for llvm-windres (using clang as
parameter), it fails. Thus, do not add this.
It's needed to be able to compile windows-arm64 version, because MSYS2
toolchain is LLVM based (instead of GCC/binutils).
* [win32] pioinfo detection for windows-arm64
This fixes "unexpected ucrtbase.dll" for native windows-arm64 ruby
binary. It does not solve issue with x64 version emulated on this
platform.
Value of pioinfo pointer can be found in ucrtbase.dll at latest adrp/add
sequence before return of _isatty function. This works for both release
and debug ucrt.
Due to the nature of aarch64 ISA (vs x86 or x64), it's needed to
disassemble instructions to retrieve offset value, which is a bit more
complicated than matching specific string patterns.
Details about adrp/add usage can be found in this blog post:
https://devblogs.microsoft.com/oldnewthing/20220809-00/?p=106955
For instruction decoding, the Arm documentation was used as a reference.
(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
`rb_vm_tag_jmpbuf_{init,deinit}` are safe to raise exception since the
given tag is not yet pushed to `ec->tag` or already popped from it at
the time, so `ec->tag` is always valid and it's safe to raise exception
when xmalloc fails.
`longjmp` can be called to raise `NoMemoryError` or to trigger GC when
`malloc` fails to allocate memory in `ruby_xmalloc` family. In such
case, `malloc` call in `longjmp` will fail again, and Asyncify unwinding
operation corrupts the memory space by using the failed pointer as
Asyncify buffer. This commit uses statically allocated buffer to avoid
such situation.
[wasm] Fix Asyncify loop exit condition for normal return
Stop calling `asyncify_stop_unwind` when the main function returns
without any unwinding. In the era when Asyncify buffers were allocated
on the stack, the `top` and `end` fields were remained in the stack
space even after the main function returned, so buffer-overflow check in
the `asyncify_stop_unwind` function passed. But now, the `top` and `end`
fields are part of the jump buffer allocated on the heap and they are
deallocated with `free` when the corresponding VM tag is popped. So, the
buffer-overflow check in the `asyncify_stop_unwind` function failed when
the main fuction returned without any unwinding, and we have to break
the asyncify loop before calling `asyncify_stop_unwind`.
Related commit: bc46b12b12
Kasumi Hanazuki
Alan Wu
Maxime Chevalier-Boisvert
Peter Zhu
Eric Mueller
tomoya ishida
Takashi Kokubun
Kevin Newton
TSUYUSATO Kitsune
Jean Boussier
Pierrick Bouvier
Stan Lo
hogelog
Yuta Saito
Jun Aruga
heyogrady