Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The Authentication component is new to Drupal 8 and has several documented bugs.
Once the known bugs and API is in a reasonable state it should be security audited prior to a release candidate as well has writing documentation on the security model.
This issue is blocked on #2371629: [meta] Finalize Session and User Authentication API.
Comments
Comment #1
chx CreditAttribution: chx commentedHere's how this works (part 1):
The
current_userservice is by default set toDrupal\Core\Session\AccountProxy.In
AccountProxyevery method exceptsetAccountgoes throughgetAccountgetAaccounton the first call, if the account is not yet does$this->setAccount($this->authenticationManager->authenticate($this->request));AuthenticationManagercalls every service tagged byauthentication_provider. Core has two: Cookie which calls the old session code and basic_auth.However, the way Cookie calls into the old session code is extremely convoluted. There is a
class SessionManager extends NativeSessionStoragewhich means Symfony gets involved at this point. To be continued.Comment #2
chx CreditAttribution: chx commentedtalked to znerol and we will revisit this as the session code becomes more complete.
Comment #3
YesCT CreditAttribution: YesCT commentedI think that means:
postponed on #1858196: [meta] Leverage Symfony Session components
?
Comment #4
YesCT CreditAttribution: YesCT commentedtagging. also we need to identify exactly the issue blocking this (maybe make that issue critical, and tag it "blocker").
Comment #5
catchComment #6
xjmComment #7
effulgentsia CreditAttribution: effulgentsia commentedComment #8
chx CreditAttribution: chx commentedLOL nope. Let me save you triage time: security is critical. Helpful chx is helpful.
Comment #9
chx CreditAttribution: chx commentedApparently this is maintainer user only. Sigh. okay.
Comment #10
xjm(Updating certain "Needs D8 critical triage" issues to a less misleading tag name.)
Comment #11
znerol CreditAttribution: znerol commentedStep 1 through 3 of #2371629: [meta] Finalize Session and User Authentication API are complete, this is step 4.
Comment #12
xjm@borisson found http://symfony.com/blog/symfony2-security-audit -- so the Symfony component itself was audited in 2011.
It could be worth looking at how Symfony handled their audits (for this issue or in general).
Comment #13
dawehnerTo be clear, this issue seems to be about more than just the session component of symfony. We have implemented authentication for our own,
so this is part of the game as well.
Comment #14
webchickSo the core committers have discussed this issue at length.
We have never blocked major releases of Drupal on security audits before. That includes releases where we have radically refactored things like the node access system, the menu/routing system, the form API, and other places where security is a must. It doesn't seem like it's really worth starting this trend now, especially for only one component of many. Additionally, a lot of this work is effectively being done by the work that's happened as part of
#2371629: [meta] Finalize Session and User Authentication API.
Therefore, downgrading this issue. It's still a worthy thing for someone to do, but doing it does not need to block D8's release.
However, what I can say that something we are have done is earmarked a chunk of the remaining D8 Accelerate funds for the Security Team, to enable them to run a program aimed at ferreting out any remaining security issues in Drupal 8, across the board. I don't know what that looks like yet, or what will ultimately get proposed (there are meetings about it next week in LA). But rest assured that we're taking security in D8 seriously. And any actual issues found will be critical/release-blocking on their own.
Comment #26
xjmComment #28
andypost