This is best learned from either ARB_framebuffer_sRGB extension spec or from the wording of the core specification. Both state it like this:
If FRAMEBUFFER_SRGB is enabled and the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer attachment corresponding to the destination buffer is SRGB (see section 9.2.3), the R, G, and B destination color values (after conversion from fixed-point to floating-point) are considered to be encoded for the sRGB color space and hence must be linearized prior to their use in blending. Each R, G, and B component is converted in the same fashion described for sRGB texture components in section 8.23.
If FRAMEBUFFER_SRGB is disabled or the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, no linearization is performed. The resulting linearized R, G, and B and unmodified A values are recombined
Also note the comments section in the extension spec (always worth reading these!):
3) Should the ability to support sRGB framebuffer update and blending be an attribute of the framebuffer?
RESOLVED: Yes. It should be a capability of some pixel formats (mostly likely just RGB8 and RGBA8) that says sRGB blending can be enabled.
This allows an implementation to simply mark the existing RGB8 and RGBA8 pixel formats as supporting sRGB blending and then just provide the functionality for sRGB update and blending for such formats.
sRGB support for floating-point formats makes little sense because [blah blah] support for all fixed-point buffers [...] would require special sRGB conversion hardware.
14) How is the constant blend color handled for sRGB framebuffers?
RESOLVED: The constant blend color is specified as four floating-point values. Given that the texture border color can be specified at such high precision, it is always treated as a linear RGBA value.