GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Base64 decode with altchars still accepts non-altchars · Issue #125346 · python/cpython

Base64 decode with altchars still accepts non-altchars #125346

New issue
Copy link
New issue
Copy link
Closed
Closed
Base64 decode with altchars still accepts non-altchars#125346
Copy link
Labels
3.15bugs and security fixesbugs and security fixesdocsDocumentation in the Doc dirDocumentation in the Doc dirstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@Anonymous3-a
Anonymous3-a
opened on Oct 12, 2024
Issue body actions

Bug report

Bug description:

If you run

>>> import base64
>>> base64.b64decode("/+/+")

it gives

b'\xff\xef\xfe'

This is expected.
If you run

>>> base64.b64decode("_-_-", altchars="-_")

It gives the same output.
This is expected.
However, if you run

>>> base64.b64decode("/+/+", altchars="-_")

It also gives the same output.
This is not expected.

This is concerning because I'm trying to use file safe base64 (urlsafe_b64decode/encode do not have validate arg, which I need). I can work around this by also checking for / and + as well.

CPython versions tested on:

3.9, 3.11

Operating systems tested on:

Linux, Other

Linked PRs

  • gh-125346: Add more base64 tests #141061
  • [3.14] gh-125346: Add more base64 tests (GH-141061) #141130
  • [3.13] gh-125346: Add more base64 tests (GH-141061) (GH-141130) #141133
  • gh-125346: Fix decoding with non-standard Base64 alphabet #141128
  • Remove duplicated tests in test_base64 (gh-125346) #141153

Activity

Next
  1. Anonymous3-a
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    on Oct 12, 2024

  2. imfeh2 commented on Oct 12, 2024

    @imfeh2
    imfeh2
    on Oct 12, 2024
    Contributor
    More actions

    It's intentional behavior that was decided upon years ago. found the following as i'm trying to fix, which related to a commit in 2016.

    cpython/Lib/test/test_base64.py

    Lines 266 to 269 in 4a943c3

    # Normal alphabet characters not discarded when alternative given
    res = b'\xFB\xEF\xBE\xFF\xFF\xFF'
    self.assertEqual(base64.b64decode(b'++[[//]]', b'[]'), res)
    self.assertEqual(base64.urlsafe_b64decode(b'++--//__'), res)

    But I think the original alphabet should be discarded because an alphabet should always remain singular. if alternative characters are provided, the original ones should be deprecated to avoid confusion and maintain consistency.

  3. picnixz commented on Oct 12, 2024

    @picnixz
    picnixz
    on Oct 12, 2024
    Member
    More actions

    Should we document this behaviour if it is not already the case? cc @serhiy-storchaka

  4. picnixz
    added
    stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
    on Oct 12, 2024
  5. viccie30
    added a commit that references this issue on Nov 20, 2024

    Throw an error on non-valid base64 strings

    ef339e8
  6. picnixz
    added
    docsDocumentation in the Doc dirDocumentation in the Doc dir
    and removed
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
    on Dec 2, 2024
  7. github-project-automation
    added this to docs issueson Dec 2, 2024
  8. github-project-automation
    moved this to Todo in docs issueson Dec 2, 2024

  9. picnixz commented on Dec 2, 2024

    @picnixz
    picnixz
    on Dec 2, 2024
    Member
    More actions

    cc @vadmium as the one who wrote this test in 2016

  10. serhiy-storchaka commented on Dec 2, 2024

    @serhiy-storchaka
    serhiy-storchaka
    on Dec 2, 2024
    Member
    More actions

    We should look at the discussion when that feature was added, but I think it is not intentional behavior.

  11. Anonymous3-a commented on Dec 3, 2024

    @Anonymous3-a
    Anonymous3-a
    on Dec 3, 2024
    Author
    More actions

    I think it is not intentional behavior

    See #125346 (comment)

  12. 17 remaining items

  13. nikhilgv commented on Jan 28, 2026

    @nikhilgv
    nikhilgv
    on Jan 28, 2026
    More actions

    Hello @serhiy-storchaka , will this fix be backported to v3.12 and 3.10?

  14. picnixz commented on Jan 28, 2026

    @picnixz
    picnixz
    on Jan 28, 2026
    Member
    More actions

    Unless this is considered a security issue, it won't.

    cc @sethmlarson

  15. serhiy-storchaka commented on Jan 31, 2026

    @serhiy-storchaka
    serhiy-storchaka
    on Jan 31, 2026
    Member
    More actions

    No, it will not be backported, because there is a risk of breaking existing "working" code, when the code uses altchars, but the input actually uses the standard alphabet. This is a programming error, but the behavior should not be changed so drastically in a bugfix release, even a warning is too much.

    User can check that neither "+" nor "/" occurr in the input before decoding. They need to do this in 3.15 to avoid warnings (or they can ignore warnings).

    In 3.15+ you can also pass the ignorechars argument (even ignorechars=b'' works) to enable more strict and explicit behavior. If "+" and "/" in ignorechars, they will be silently ignored, otherwise they will be errors.

  16. Anonymous3-a commented on Jan 31, 2026

    @Anonymous3-a
    Anonymous3-a
    on Jan 31, 2026
    Author
    More actions

    Should the issue be closed now, then?

  17. serhiy-storchaka
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    3.15bugs and security fixesbugs and security fixes
    on Feb 1, 2026
  18. serhiy-storchaka
    closed this as completedon Feb 1, 2026
  19. serhiy-storchaka
    added
    stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
    on Feb 1, 2026

  20. Kanishk-Bansal commented on Feb 2, 2026

    @Kanishk-Bansal
    Kanishk-Bansal
    on Feb 2, 2026
    More actions

    Can we expect a backport for 3.10 & 3.12 as well?

  21. picnixz commented on Feb 2, 2026

    @picnixz
    picnixz
    on Feb 2, 2026
    Member
    More actions

    No, and the rationale is just a few comments above.

    Reacted by Seth Larson
  22. bmwiedemann
    added a commit that references this issue on Feb 14, 2026

    Update python314 to version 3.14.3 / rev 32 via SR 1332989

    c794a09
  23. thunder-coding
    added a commit that references this issue on Feb 15, 2026

    pythongh-125346: Deprecate accepting standard Base64 alphabet when al…

    41b3d35
  24. bmwiedemann
    added a commit that references this issue on Feb 18, 2026

    Update python312 to version 3.12.12 / rev 43 via SR 1332782

    82a6b4d
  25. hauntsaninja
    added a commit that references this issue on Apr 16, 2026

    Initial support for Python 3.15.0a8 (#21255)

    ebaa73a
  26. JukkaL
    added a commit that references this issue on Apr 21, 2026

    Initial support for Python 3.15.0a8 (#21255)

    ba28610
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.15bugs and security fixesbugs and security fixesdocsDocumentation in the Doc dirDocumentation in the Doc dirstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    • docs issues
      Status
      Todo
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions
    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.