SASL_DECODE(3)
π SASL_DECODE(3) π
okay bestie so this is sasl_decode from the Cyrus SASL docs, section 3 of the manual, and it's genuinely one of the most useful little functions in the whole library. come sit with me, we're gonna get you fluent in this π
β¨ NAME β¨
sasl_decode β Cyrus SASL documentation, babes π
πΈ SYNOPSIS πΈ
#include <sasl/sasl.h>
int sasl_decode(sasl_conn_t *conn,
const char * input,
unsigned inputlen,
const char ** output,
unsigned * outputlen);
yes the indentation is a little chaotic in the original, we don't talk about it, it's iconic π
π¦ DESCRIPTION π¦
int sasl_decode(sasl_conn_t *conn,
const char * input,
unsigned inputlen,
const char ** output,
unsigned * outputlen);
so like. sasl_decode decodes data received. that's the whole vibe. after a successful authentication you should be calling this function on all data you receive, no skipping, no "I'll do it later" π. it takes data that's in encrypted or signed form and turns it back into plain data. and here's the cute part β if there was no security layer negotiated, the output is identical to the input. literally a mirror. no notes. β¨
π§ Parameters π§
connβ is the SASL connection context π«outputβ contains the decoded data and is allocated/freed by the library. so like, don't you dare touch that memory management, it's the library's job bestie, hands off π«Άoutputlenβ length of output π
β οΈ one should not givesasl_decodemore data than the negotiatedmaxbufsize(seesasl_getprop(3)). respect the buffer limit, it's giving boundaries and we love that for it π§
and a lil plot twist that trips people up every single time: note that sasl_decode can succeed and outputlen can be zero π that's not a bug, that's not an error, that's just the vibe. if that happens, simply wait for more data and call sasl_decode again. periodt π
π₯ RETURN VALUE π₯
SASL callback functions should return SASL return codes. see sasl.h for a complete list, it's all in there iykyk π
SASL_OK indicates success ππ
Other return codes indicate errors and should be handled. like actually handled, not ignored, we're not doing that today π¨
π SEE ALSO π
RFC 4422:saslman:sasl(3)sasl_encode(3)sasl_errors(3)
(the sasl_encode one is literally just this but backwards, they're a matched set, soulmates fr fr π)
π AUTHOR π
The Cyrus Team π«‘
π COPYRIGHT π
1993-2016, The Cyrus Team
and that's the whole page bestie!! this dropped as version 2.1.28 back on February 18, 2022, and yes it's still SASL_DECODE(3) energy around here πβ¨π go forth and decode responsibly, mwah π«Άπ
π¦ where this page comes from
- alpine 3.22: cyrus-sasl-doc 2.1.28-r8 Β· BSD-3-Clause-Attribution AND BSD-4-Clause
- alpine 3.23: cyrus-sasl-doc 2.1.28-r9 Β· BSD-3-Clause-Attribution AND BSD-4-Clause
- alpine 3.24: cyrus-sasl-doc 2.1.28-r9 Β· BSD-3-Clause-Attribution AND BSD-4-Clause
- centos-stream 10: cyrus-sasl-devel 2.1.28-27.el10 Β· BSD-Attribution-HPND-disclaimer
- fedora 43: cyrus-sasl-devel 2.1.28-33.fc43 Β· BSD-Attribution-HPND-disclaimer
- fedora 43: cyrus-sasl-devel 2.1.28-33.fc43 Β· BSD-Attribution-HPND-disclaimer
- fedora 44: cyrus-sasl-devel 2.1.28-35.fc44 Β· BSD-Attribution-HPND-disclaimer
- fedora 44: cyrus-sasl-devel 2.1.28-35.fc44 Β· BSD-Attribution-HPND-disclaimer
- opensuse-leap 16.0: cyrus-sasl-bdb-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-bdb-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-bdb-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-bdb-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- opensuse-leap 16.0: cyrus-sasl-devel 2.1.28-160000.4.1 Β· BSD-4-Clause
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms