Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link compression added to rippled-example.cfg #4739

Closed
wants to merge 10 commits into from

Conversation

florent-uzio
Copy link
Collaborator

@florent-uzio florent-uzio commented Oct 3, 2023

High Level Overview of Change

This PR adds the link compression setting to the rippled-example.cfg file in the second section "Peer Protocol".

It solves #4656

Context of Change

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Tests (You added tests for code that already exists, or your new feature included in this PR)
  • Documentation Updates
  • Release

Future Tasks

@intelliot
Copy link
Collaborator

If/when the default changes, this will be updated at that time to reflect the updated default.

@florent-uzio
Copy link
Collaborator Author

@intelliot Should I wait before merging this PR to see if #4387 gets merged soon?

Copy link
Collaborator

@gregtatcam gregtatcam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@intelliot
Copy link
Collaborator

@intelliot Should I wait before merging this PR to see if #4387 gets merged soon?

No, I don't think there's a need to wait. This is accurate as of develop now, and it's a trivial fix to update this to reflect the updated default, if that change occurs.

@intelliot intelliot added this to the 2.0 milestone Oct 6, 2023
@intelliot intelliot added the Documentation README changes, code comments, etc. label Oct 6, 2023
florent-uzio and others added 8 commits October 6, 2023 14:15
Address a stack-use-after-scope issue when using rvalues with
`soci::use`. Replace rvalues with lvalues to ensure the scope extends
beyond the end of the expression.

The issue arises from `soci` taking a reference to the rvalue without
copying its value or extending its lifetime. `soci` references rvalues
in `soci::use_container` and then the address in `soci_use_type`. For
types like `int`, memory access post-lifetime is unlikely to cause
issues. However, for `std::string`, the backing heap memory can be freed
and potentially reused, leading to a potential segmentation fault.

This was detected on x86_64 using clang-15 with asan. asan confirms
resolution of the issue.

Fix XRPLF#4675
Make transactions and pseudo-transactions share the same commonFields
again. This regularizes the code in a nice way.

While this technically allows pseudo-transactions to have a
TicketSequence field, pseudo-transactions are only ever constructed by
code paths that don't add such a field, so this is not a transaction
processing change. It may be possible to add a separate check to ensure
TicketSequence (and other fields that don't make sense on
pseudo-transactions) are never added to pseudo-transactions, but that
should not be necessary. (TicketSequence is not the only common field
that can not and does not appear in pseudo-transactions.) Note:
TicketSequence is already documented as a common field.

Related: XRPLF#4637

Fix XRPLF#4714
When a new transactor is added, there are several places in applySteps
that need to be modified. This patch refactors the code so only one
function needs to be modified.
…F#4721)

Context: The `DisallowIncoming` amendment provides an option to block
incoming trust lines from reaching your account. The
asfDisallowIncomingTrustline AccountSet Flag, when enabled, prevents any
incoming trust line from being created. However, it was too restrictive:
it would block an issuer from authorizing a trust line, even if the
trust line already exists. Consider:

1. Issuer sets asfRequireAuth on their account.
2. User sets asfDisallowIncomingTrustline on their account.
3. User submits tx to SetTrust to Issuer.

At this point, without `fixDisallowIncomingV1` active, the issuer would
not be able to authorize the trust line.

The `fixDisallowIncomingV1` amendment, once activated, allows an issuer
to authorize a trust line even after the user sets the
asfDisallowIncomingTrustline flag, as long as the trust line already
exists.
@florent-uzio
Copy link
Collaborator Author

Closing this one and opening a similar one to have clear verified commits required to merge:
#4753

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation README changes, code comments, etc.
Projects
Status: 📋 Backlog
Development

Successfully merging this pull request may close these issues.

8 participants