Сравнить коммиты
2 Коммитов
3e3e24a882
...
d115d0d683
| Автор | SHA1 | Дата |
|---|---|---|
TekotovaVA
|
d115d0d683 | 2 лет назад |
|
TekotovaVA
|
2b5021fdb3 | 2 лет назад |
@ -0,0 +1 @@
|
||||
/curl-8.0.1_9-win64-mingw
|
||||
@ -0,0 +1,3 @@
|
||||
{
|
||||
"CurrentProjectSetting": "Нет конфигураций"
|
||||
}
|
||||
@ -0,0 +1,7 @@
|
||||
{
|
||||
"ExpandedNodes": [
|
||||
"",
|
||||
"\\bin"
|
||||
],
|
||||
"PreviewInSolutionExplorer": false
|
||||
}
|
||||
Двоичный файл не отображается.
Двоичный файл не отображается.
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
Двоичный файл не отображается.
Двоичный файл не отображается.
Двоичный файл не отображается.
@ -0,0 +1,10 @@
|
||||
{
|
||||
"version": "0.2.1",
|
||||
"tasks": [
|
||||
{
|
||||
"taskLabel": "задача-curl-8.0",
|
||||
"appliesTo": "/",
|
||||
"type": "launch"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -0,0 +1,189 @@
|
||||
SHA2-256(./bin/curl-ca-bundle.crt)= fb1ecd641d0a02c01bc9036d513cb658bbda62a75e246bedbc01764560a639f0
|
||||
SHA2-256(./bin/curl.exe)= 5174c385297927f044f975c423926d07add799ffc6bb546c66f28745cf8ece47
|
||||
SHA2-256(./bin/libcurl-x64.def)= 1a0493c4587747d399ab1b5bd445702d776adc3aefb9cbcc6e5f4770f0330a98
|
||||
SHA2-256(./bin/libcurl-x64.dll)= bde9bee3cfb25bd0c348ad59a0ebdc1f06734f8f5e3c3580a770ccf3b4fb3485
|
||||
SHA2-256(./include/brotli/decode.h)= a9665d09f77df18f8a1f4c948610474ebd8758ff3f3a0714842af0a12d263ee6
|
||||
SHA2-256(./include/brotli/encode.h)= dfc6f8e43b30e2e88c5cc9d1a4842aa967aa399e2ccd4eea3fb134a990216812
|
||||
SHA2-256(./include/brotli/port.h)= 2cffc986439dfac586589f538db721155229ac615dfad16300dd70aff7b718f6
|
||||
SHA2-256(./include/brotli/types.h)= 96c9330e790aa6fe53f4cdd328d0a4b98e361b82913baa3219db73aadb11272c
|
||||
SHA2-256(./include/curl/curl.h)= 3c35502a677855429e5158fb445c6db11aa8eab1baabda07be5e3bf8a68a9fda
|
||||
SHA2-256(./include/curl/curlver.h)= 0643bb8ed1f79eaaf8758304262eb2ed1e8a418344ae277e33850495aba9444b
|
||||
SHA2-256(./include/curl/easy.h)= b9c5aed96b32f76fd09338cb3b4066c8082b702165960e4026a0a4e0d3612634
|
||||
SHA2-256(./include/curl/header.h)= 614be48a86f4e5d304c5aa40ef1c85245e25b97732921c3631840146669d992f
|
||||
SHA2-256(./include/curl/mprintf.h)= 637de71d034d478ad47237c376c02eefa50514ada9f2a037ca42c6ffdf66c3dc
|
||||
SHA2-256(./include/curl/multi.h)= 3dd2ff1eeea4298f08d0aa5c6a46140644b6ee2e710ee8bc64513e732f32975c
|
||||
SHA2-256(./include/curl/options.h)= 5716018d27e783283825bed2a8a051190487722fdeb64b7aa2d03a997e99b8d1
|
||||
SHA2-256(./include/curl/stdcheaders.h)= d7588b86814a35ffc3766ff6242e6f6705e04401fc9c208a195caff3503af81c
|
||||
SHA2-256(./include/curl/system.h)= afdcf4eff603a098a00a039b50a2c7576f0b1df24b02b25dd2bcf770f2472c9c
|
||||
SHA2-256(./include/curl/typecheck-gcc.h)= d185380689acef7cee201b07cfbf20aa29f3ab7f19ba08895f927cffe028edb5
|
||||
SHA2-256(./include/curl/urlapi.h)= dd631108b8503994fcf6c416eeaea2973822fc778ea2cff440c6b6e21c8712d2
|
||||
SHA2-256(./include/curl/websockets.h)= df5effcf55908ce67501008f99ce1ac4d01cfc48d2788d6a106dc6bfda009078
|
||||
SHA2-256(./include/gsasl-mech.h)= 3d264823c4a12181b05240c3751a8f91a09bf33a692d9bd4f5e92088f18c5ce8
|
||||
SHA2-256(./include/gsasl-version.h)= 1648f62390bf3570313cc1230f016233e01619cc64a077feba7a962f9be52fc9
|
||||
SHA2-256(./include/gsasl.h)= 4b2a4ccdc45e8c3e03089e05a250d58b7a740871a2f734e8ad6d6b350c220c85
|
||||
SHA2-256(./include/libssh2.h)= 2ad4b44156ccee35b2dc0611485d60b5a12569e4b1317cb06753d9585b657bf8
|
||||
SHA2-256(./include/libssh2_publickey.h)= 2d419bdfbc155cec62cc23d7cb87f3d9361c4f26ce3b3910c74cef715bd2e70b
|
||||
SHA2-256(./include/libssh2_sftp.h)= 8a0c63c323edc42286cc608f9a53cebe46ac91432e1080a8520ab69d3caeadbf
|
||||
SHA2-256(./include/nghttp2/nghttp2.h)= 0d1d48c9ea099a6f4dbe39491b9c0f68f2c2a4b99898e568da34f59a9017029e
|
||||
SHA2-256(./include/nghttp2/nghttp2ver.h)= 565dc92c07698bab1a3eea480012605d5e8fb565c1649419cad46283d5e0bccc
|
||||
SHA2-256(./include/nghttp3/nghttp3.h)= 16dbc7a459c3490fd67be00bd7193a39ce3b412ce8fa008472cc907166acebe0
|
||||
SHA2-256(./include/nghttp3/version.h)= 8609194d4646d3f5132c94c9ecf24b9b4e2b8f5757b1a0b04ff0ce3e481217c8
|
||||
SHA2-256(./include/ngtcp2/ngtcp2.h)= b4d51bd8eeb6443fc0c435395a58396177ce0670c2d6c9e95297c6ff8a616227
|
||||
SHA2-256(./include/ngtcp2/ngtcp2_crypto.h)= b0406acffec30d47df3582613f378a9681d3040aee0a92f251048ec5edebe034
|
||||
SHA2-256(./include/ngtcp2/ngtcp2_crypto_openssl.h)= 342791e1cd6181ff575d9a220db1cb1dab79f328774b0e69b3618df010b5a389
|
||||
SHA2-256(./include/ngtcp2/version.h)= a82a7ed097010cda262e1850615bb237cdcb160c3dac1bc95a8f0544869812c3
|
||||
SHA2-256(./include/openssl/aes.h)= 27aaa89367b022b12b66cf52c3c2d68f6761965ac36f3f1153202fa44692ad0e
|
||||
SHA2-256(./include/openssl/asn1.h)= 6e9e4042d0cf76eb3b9f5a4d299154dd1d95b8b3c5b645fde7dbe83e7f05b3c9
|
||||
SHA2-256(./include/openssl/asn1_mac.h)= 5a0d1d59316bc398bc63af0f1dcf377fb66c3e3132d4c45400c9dbc2003e24b5
|
||||
SHA2-256(./include/openssl/asn1err.h)= 75c4b045fef75587c0df5c658b7466b74ad42755368a56cf6ff43581aa5768c6
|
||||
SHA2-256(./include/openssl/asn1t.h)= 6c6189504732c30bbf7363676b07fa6fc34330e960b2921b186f9d56deeec000
|
||||
SHA2-256(./include/openssl/async.h)= 49369e1569d424f56f016865a34d59b676984e7f67f459e6514241afcd818252
|
||||
SHA2-256(./include/openssl/asyncerr.h)= 154f003cfbf49040a04d9aac459cf5009a5a1d76298b222d66ba5b5a4e3721af
|
||||
SHA2-256(./include/openssl/bio.h)= 76aed534c208e7e78f141b837f5c1f15f20c01fd18a7599ee8b704078529cd89
|
||||
SHA2-256(./include/openssl/bioerr.h)= 348571893bca9600b9f790af5c6a02b40bffd83a718450a54a8022c70fef1a14
|
||||
SHA2-256(./include/openssl/blowfish.h)= fb4b19b7730d1cc7ff2b9da1435a506ad0ef50263bd168c5ff24214a06580282
|
||||
SHA2-256(./include/openssl/bn.h)= 7a439d7b7fcb7b2bee94012f7eab7f130e8abf6691a738ec2bd2c6ee1d6de2de
|
||||
SHA2-256(./include/openssl/bnerr.h)= f0dfac26985a7ae40174e90173df9f95b15bba4d3768290746d7258ff1b0ae64
|
||||
SHA2-256(./include/openssl/buffer.h)= c87b52702746e224e6242f4a2a2070b007502ea92063b41df2c4f6bec11c37ca
|
||||
SHA2-256(./include/openssl/buffererr.h)= 73f33a7b4406477a0eaf9d0ec42f43b2594167b1d6b84175f378cf5b0de07c12
|
||||
SHA2-256(./include/openssl/camellia.h)= d1cee6e44668fba0e46c38db7394aa094c6cd2a25b97dbcfcc6f0ff4414f8ebf
|
||||
SHA2-256(./include/openssl/cast.h)= 654ac650ae74ca5e9a87ab46c1205157a7489097d005fdccc4c52912cfcefa55
|
||||
SHA2-256(./include/openssl/cmac.h)= b26f8ddb9f60eef2601a84a5455c11060e028d8ce700cae682c4a02ffe2f2ca2
|
||||
SHA2-256(./include/openssl/cmp.h)= 22b8e1127029459711ec45a08630228b688ed47deb4f4d62111f39f4fe3c2e1b
|
||||
SHA2-256(./include/openssl/cmp_util.h)= 7a982bac5840812b486176102b1fe8b48dda8cce0fe94f2d35aff5057a99004e
|
||||
SHA2-256(./include/openssl/cmperr.h)= d22b5995d615e5374041784cd1af99b4ef349b0cd6e2ac852c6d1dbf9aed8e90
|
||||
SHA2-256(./include/openssl/cms.h)= 9564be579e014db5a53f5f38c4c16e1b3c76010965f6172a79fb96c89768636e
|
||||
SHA2-256(./include/openssl/cmserr.h)= 9db6b3e5e7d1a82c7bffbde27a91f5ace1ddf8c11f5f5a55b90b3df9a67f4ab6
|
||||
SHA2-256(./include/openssl/comp.h)= 44ad0613758e8cf84d9ec4f40cf50cbb735b16e659f7e9fd30c2155585d94199
|
||||
SHA2-256(./include/openssl/comperr.h)= 656851389d8f21bc80b566248d7849c6b4ecbd5b178592b8e099c6457b37d87c
|
||||
SHA2-256(./include/openssl/conf.h)= d6fc24e176f2ad3a7020ce3d982c282c8e048fc6e2198f5e98eac5d10e308874
|
||||
SHA2-256(./include/openssl/conf_api.h)= a66bcc69464235679980efc4a687a4fe036388da91173809ca45c0a3cfe47a5b
|
||||
SHA2-256(./include/openssl/conferr.h)= 4b724e0a69104b630c334787994273c619f4dc0b509a0b03271de5a7e2539fcb
|
||||
SHA2-256(./include/openssl/configuration.h)= 273fb44e320dcc0dcf53f0c0c8946e9da72e18a4803512c5e62eab26744b8a89
|
||||
SHA2-256(./include/openssl/conftypes.h)= e8f6697076d2464eaecfe2cdae8d2045388c53da2372fd52df5f6cfdc4d63375
|
||||
SHA2-256(./include/openssl/core.h)= 2981b182ac8930f17b136665b61f1c34c0cfdb4e122f19bd75d7ff552ff5e736
|
||||
SHA2-256(./include/openssl/core_dispatch.h)= ab6ac7673333b11035a437640ac729e537a7c66949e4e1eb953d24f55eb40fee
|
||||
SHA2-256(./include/openssl/core_names.h)= 86a2c73a71940bf61b8523b46bf81383c86e18e30c0608eae7667cbeae4019a4
|
||||
SHA2-256(./include/openssl/core_object.h)= 7a7172d30597e3a3e06c4e67a049d1335aa6f7d5b49641abba8fd4d5a1c07563
|
||||
SHA2-256(./include/openssl/crmf.h)= 35f535d165e6d33782205d433a00dcc16b402f669f67b203d8400e03e239a471
|
||||
SHA2-256(./include/openssl/crmferr.h)= c08a40103c0c6d0d7d9ad0e2781db1f19829d29193d115d38b4d0271d13fecf9
|
||||
SHA2-256(./include/openssl/crypto.h)= e38be34cd9c27f3f7af7acf4039357e79b4af2465d61f21ffb9687901fa8e325
|
||||
SHA2-256(./include/openssl/cryptoerr.h)= 2035467a49cd64e952be41ce9a8754652acf31e481f2d710e14a0a4fc870cd4f
|
||||
SHA2-256(./include/openssl/cryptoerr_legacy.h)= 870042252331e89723d31079469104cafd676f0fedcbe0d99f56f3e8862fff8d
|
||||
SHA2-256(./include/openssl/ct.h)= 8934546579df1f30bf22e1e8cd4872a0c2dbc54f5157f92534491c0f9571d956
|
||||
SHA2-256(./include/openssl/cterr.h)= 562bfe4ac984ebfef4fb91bdbe0a649d157f5057ab61ffee3a844d23f7c72c0a
|
||||
SHA2-256(./include/openssl/decoder.h)= 8419fd9e4e333fd477238bbad4ff875d5657b02cc39635c3a5c15f3a5bc7f0f2
|
||||
SHA2-256(./include/openssl/decodererr.h)= a785fb95930e8b4a18054f77b7d5143d44673f4ca57682899bc2bf3464cafccf
|
||||
SHA2-256(./include/openssl/des.h)= bb13c7c5e13f3402d674fa88994b92ed72d6cdc1116707765d28bd7e0de31285
|
||||
SHA2-256(./include/openssl/dh.h)= 0ffdb3e46f8930e13e4dfbe7d6bc76c703c20aa763d9613a69aca1981fa41bbf
|
||||
SHA2-256(./include/openssl/dherr.h)= 930731f5b68298def56df6fb0a3cdeb5534cd22543bef9a446fc73d680e4ce5a
|
||||
SHA2-256(./include/openssl/dsa.h)= 702b50b9877cc54e7b19b87c5b9584a208aa5b25a93f840f4d109f6bd18a6238
|
||||
SHA2-256(./include/openssl/dsaerr.h)= 69c2ecff5f62898461bc521ea918abd2a673206dd5e8d43288ad25d2c012f163
|
||||
SHA2-256(./include/openssl/dtls1.h)= 1d1f404032a9eb31408c1f10bdff554d5740fb345b64b86fb74da8df95fbd901
|
||||
SHA2-256(./include/openssl/e_os2.h)= edc97525ece6d817c910da30f229bba4ad419bb0da4c49c9addb4f0ae751753f
|
||||
SHA2-256(./include/openssl/ebcdic.h)= 75a668c25c97853d5ba37ebce060a15152573242e3729d42830eba1daa642404
|
||||
SHA2-256(./include/openssl/ec.h)= e61ffa1cbfd7bac0114bbd73537b8b39843cbcbd3423c068bf07dbdc1c21e3dc
|
||||
SHA2-256(./include/openssl/ecdh.h)= 5b99fdd1dfea38640ed8a506fb9b66db381cc26a1254448a81cc6b161e41850f
|
||||
SHA2-256(./include/openssl/ecdsa.h)= 5b99fdd1dfea38640ed8a506fb9b66db381cc26a1254448a81cc6b161e41850f
|
||||
SHA2-256(./include/openssl/ecerr.h)= ce4fec7ee41de25a20abb7a9f00fe93305793a7bd2023d434b9aa6f64f91058a
|
||||
SHA2-256(./include/openssl/encoder.h)= 907d2f061c2972447d3f0c1cfc149c78791b1e4bdc131ad5a3eed1d084c76b41
|
||||
SHA2-256(./include/openssl/encodererr.h)= 63504766e9fcf36fe1527d95fe21460574896da187c60707bfa68254a35693b7
|
||||
SHA2-256(./include/openssl/engine.h)= b48e5406717b26f41085dad8cc553e78c6cc54ea936df8ff1aa1312f32a6c053
|
||||
SHA2-256(./include/openssl/engineerr.h)= 8616a93b1b1bd8d1221844834817c28b7da78be1649a5b1780d9ea65fba8807c
|
||||
SHA2-256(./include/openssl/err.h)= 3cc1e1dbda3781fec4f515b1d61e31c39c6e76b802b3150e7c977b0b0a213608
|
||||
SHA2-256(./include/openssl/ess.h)= 073ef3e4de09dc3e35117c37ba074e5c78a5041e1263768d475ee0df650c003a
|
||||
SHA2-256(./include/openssl/esserr.h)= e791193e891b0784670d5410539aeea9d2a8591de71495b4add6e7dbf9dc22cd
|
||||
SHA2-256(./include/openssl/evp.h)= afa819625e3ec99c970229a92915fe6e397c46e620c8b904f163a551bed042d8
|
||||
SHA2-256(./include/openssl/evperr.h)= 7fab5bade4441300fa7ffe721ca2eb361835998db7d386f8f1be7db5b7596c3f
|
||||
SHA2-256(./include/openssl/fips_names.h)= 6332c39728d4406299deaf5e161de6583294e4f5ec172bdbce080a354761566f
|
||||
SHA2-256(./include/openssl/fipskey.h)= 7bca4b30e836685232c7cc0323059680cc367df6390e88c71843208f1b6df204
|
||||
SHA2-256(./include/openssl/hmac.h)= e49fbe0086f8fbefa5648eef70bc84e8090a9226a1e3c6e856499373004aed0a
|
||||
SHA2-256(./include/openssl/http.h)= 70777f3993fce1e96dd54a1c8f839da604753f9c92cdafcaa5f268ce608bb0cd
|
||||
SHA2-256(./include/openssl/httperr.h)= b50562e98d92c08e47e2b1b0bcf5652820b2a774652968a1188f9f2d87f2fe87
|
||||
SHA2-256(./include/openssl/idea.h)= 239122df15e738d7552dd76850c55a9ffe0136f33506c23d9058215a1255af66
|
||||
SHA2-256(./include/openssl/kdf.h)= 41756fe038443d1d270458d53d6e42ea78d12d980728b6a9284fa259958ea00a
|
||||
SHA2-256(./include/openssl/kdferr.h)= 3d9f27fffdb49e0ece9d5a62adbb9cc42c56262b00cc8ce7f956b2cb05a2a22d
|
||||
SHA2-256(./include/openssl/lhash.h)= 0c457611f11e6c4fd574738f133618b538f5e0011e9bb9d944f223cf91ce8e92
|
||||
SHA2-256(./include/openssl/macros.h)= 30823bbca2920f6897f92a3372eec678240b94e1a9d3da6090f70207b8e1bd56
|
||||
SHA2-256(./include/openssl/md2.h)= 4add77ed047736979dc442a49d42921cce21e654a2dceef058d0191aa2d3c941
|
||||
SHA2-256(./include/openssl/md4.h)= 0472e597d139b44dd7d78d9093a5d8109417d18e9955fc940f1ea3e2e892ab44
|
||||
SHA2-256(./include/openssl/md5.h)= 308c901ec1a28f9b0098717f689ca63e104ce805050802d38b8f122d85ab2c78
|
||||
SHA2-256(./include/openssl/mdc2.h)= 42b844c9ae9e00e7c0b0e28858b8b3db7b8abf7e514e5e63f43456371ed3384b
|
||||
SHA2-256(./include/openssl/modes.h)= 4a8b3b1dafc15798a3b2bef0e3885275746e7fae73a0d96e55da55261554ba52
|
||||
SHA2-256(./include/openssl/obj_mac.h)= c1d31f32a3dbc9dea1db10f322b4b46a24c3d4411fe54630df59fa46fc2b583a
|
||||
SHA2-256(./include/openssl/objects.h)= 5fc6f3f0dd5e46fd409cb51ae1b331fec799fb6ef4b5efdc8ffbe264e5e83997
|
||||
SHA2-256(./include/openssl/objectserr.h)= e17a8d7f62a1ef257fd90e604d4293bf02d5f81ae8198efe1e197c5b27baeb8c
|
||||
SHA2-256(./include/openssl/ocsp.h)= 99d8de16ff3d39cea37359f0dc52dad8632702db19bfdb2a9ea8f8a79997a519
|
||||
SHA2-256(./include/openssl/ocsperr.h)= 178329cfc042d3f1eb6e179206d844de41ba05ee4ac0ed9e3e6c861fb49d68ea
|
||||
SHA2-256(./include/openssl/opensslconf.h)= 890184233890bacd52fd420fef07befad411b9a318b97efbf36f46673d3e7841
|
||||
SHA2-256(./include/openssl/opensslv.h)= 973e9d2652e7f22fcfd8b154dc3f002d51e0e5bdca3a66027c69f5dfc36de92a
|
||||
SHA2-256(./include/openssl/ossl_typ.h)= 76cb203ef3bcd305f4171e1d33f3f3319dee6354c2433493e5e9068aa79672fd
|
||||
SHA2-256(./include/openssl/param_build.h)= 3bf39b1037256466f1a89868621b2b62f1d05e63064159e60727041b170d55e3
|
||||
SHA2-256(./include/openssl/params.h)= 10d8e0157e339ee01f3b9c60c4b5bc60e6d4edce1084f0c9589ff75bf3a9f693
|
||||
SHA2-256(./include/openssl/pem.h)= 26e59ed8238091baafa52e477910a0fb1c8d2447a23bf330d017650bee5ca105
|
||||
SHA2-256(./include/openssl/pem2.h)= a34a1607983b5f32be8ca49e75c3b41f1c9413b4eb777af144958283ecbd3922
|
||||
SHA2-256(./include/openssl/pemerr.h)= 843df90b1b434eed626bb6b8bccd5f6ed530e592d706584f56a725d254d8a5d2
|
||||
SHA2-256(./include/openssl/pkcs12.h)= 2c6b6c18968d8c78935c585a96e641102294964939f93a60c87fd6fa55425278
|
||||
SHA2-256(./include/openssl/pkcs12err.h)= b692b1a2c7fc06002dee07a868f0ec394e9b7f20b5e151f78e0941e143c2d2d4
|
||||
SHA2-256(./include/openssl/pkcs7.h)= 4cf978d2986cfea67438b48b9577f7017ca5dcff1dc81eadb7d702d7583dee40
|
||||
SHA2-256(./include/openssl/pkcs7err.h)= 9fe7a51f3de13b1fd03b319c64b8bd287164eb6ce7d3481994141c0be51396d5
|
||||
SHA2-256(./include/openssl/prov_ssl.h)= 1f5c121c02d31f695bff708396e0512286fa04dee67f12ab895c0c558ba33f20
|
||||
SHA2-256(./include/openssl/proverr.h)= c6524a35fda47769544a58905a44467a0fe84db2bf644168c46c25e51f6e5686
|
||||
SHA2-256(./include/openssl/provider.h)= b9e5b46a26f7e7ec383fe540404092e4d76ae54b5822744e4ba0750ef8d2cac0
|
||||
SHA2-256(./include/openssl/quic.h)= 8137476df19d360dc5da219cfe824dafa5b2521021f4337e7655d6368003fcb6
|
||||
SHA2-256(./include/openssl/rand.h)= bb9a0269d976465e31ae7c22a022b39b55e7f5b003ddf82f5b9d0e009da482d9
|
||||
SHA2-256(./include/openssl/randerr.h)= 80260d41625b9ed9f727e8553a65a111645b3c013df8cc8fa6a718d32b643c88
|
||||
SHA2-256(./include/openssl/rc2.h)= 08c6865d169a300e8bc818bd810f80ffb8a21d69e97dad88e400b586d0f3e965
|
||||
SHA2-256(./include/openssl/rc4.h)= ea45836c253246c1d6f1b16b360dbb59322e26e28bfc54881d698e7cd5057666
|
||||
SHA2-256(./include/openssl/rc5.h)= 968c96ead08204edb8148981094700cbc3338ed0613c4469da5ab4675fa1ce29
|
||||
SHA2-256(./include/openssl/ripemd.h)= 2e28edeb6613516db89e28c9d962301f4fe7b38366ebdd1d35933f3491d57b9d
|
||||
SHA2-256(./include/openssl/rsa.h)= 087c43978b2728f8797cf60752931b55157ab8812fc92fc5dd172fc99efe2a35
|
||||
SHA2-256(./include/openssl/rsaerr.h)= a745e6b2835af7bb933e78870a270d51ab33778fe10a5cd377422d4b9587dcf0
|
||||
SHA2-256(./include/openssl/safestack.h)= bcd1a766d9043cf69f93414f8f5f7460a7f8b380c983ba986284ed5ad7947a0e
|
||||
SHA2-256(./include/openssl/seed.h)= 0d6d206f240f7bd6fa28cd4ec66b2b878f199af3ce6eda172af9fe31ebb71586
|
||||
SHA2-256(./include/openssl/self_test.h)= 780a17cecfd4f821d1293ababb5f560a111c67d32eace330d22ce40f03fee84d
|
||||
SHA2-256(./include/openssl/sha.h)= 06500535b9b3d9742e745558dc02e52d0df6d75b038457d4f6c374ed68d39eaf
|
||||
SHA2-256(./include/openssl/srp.h)= 9931b618255b70a35ef5b554ceee202163a3ae693e926fc1ed2a74a91d3fe595
|
||||
SHA2-256(./include/openssl/srtp.h)= d2b97e90531bf9cdb086d9943a518bc474aebaa0aef02f1d41e8113fe944c9d9
|
||||
SHA2-256(./include/openssl/ssl.h)= 6be04d31a681de98c80de4c33ea46e222575557dc151086f1bb3bb3e6e4633f5
|
||||
SHA2-256(./include/openssl/ssl2.h)= 92e3330e2867bf17d3b305ba0f6fe6b073ad4bdb9db519e4224bbd993f1e9cb7
|
||||
SHA2-256(./include/openssl/ssl3.h)= 5ce26c99d8a0fffe062a4293f01f6d55619b4e1b8f75bf0065fb3faa2ac512e9
|
||||
SHA2-256(./include/openssl/sslerr.h)= f26757bbc37c71c4897cf81a6a6fa653d2f78de2b342c96503393d3abcb08a4b
|
||||
SHA2-256(./include/openssl/sslerr_legacy.h)= 98401ca29f46694fff11304801d995015a7e4a81afe0db0a9a79a0bdde9e03d8
|
||||
SHA2-256(./include/openssl/stack.h)= 69f94382a15a3c4cfd1dda32108db5234727b36ed0e25f1fb12e0993c7b5ac95
|
||||
SHA2-256(./include/openssl/store.h)= cfd4ee1777782d642da53a045d253ede58f0f0463647e6d4f352953b26e2e058
|
||||
SHA2-256(./include/openssl/storeerr.h)= 370277e107a1b979ff5e0bd28f5adb92e066d41831ac37ce7108d2a1b84376f6
|
||||
SHA2-256(./include/openssl/symhacks.h)= 68b54776fa15943f3f018be6c7dc7a8847c9f512fb5eeec4f093804197dc2dfa
|
||||
SHA2-256(./include/openssl/tls1.h)= 99fa5ab66437bd5bfe73359d5a0f1b8b86b0ea14fa2a8378ef3137ee34356e24
|
||||
SHA2-256(./include/openssl/trace.h)= b875c655debc29d9c910db5522feb97edf147798dea6f2fcad8f9a85abb18a1a
|
||||
SHA2-256(./include/openssl/ts.h)= 886fcc2d0687b1f3d430d8091067c4bf9a73df2102e1581ac2a1bcfc5f6cf515
|
||||
SHA2-256(./include/openssl/tserr.h)= 0d851cb9db84c48bb8a9871a988950fd0b62ecc854b11641e3e9a07fa191a6f6
|
||||
SHA2-256(./include/openssl/txt_db.h)= 1a6a6b331ef3cc6c632f782e8da2fa81aaeeac56e4d0b2fb3016f936805be257
|
||||
SHA2-256(./include/openssl/types.h)= 0a99b2c6f9a99ce25038eb98790eaf0f6c3dafaccfe37d6ff126d54f2387375d
|
||||
SHA2-256(./include/openssl/ui.h)= 0dca137a0686620b4f159b9ce78a45a772f04d670e2b24a42feb53273cb2fd81
|
||||
SHA2-256(./include/openssl/uierr.h)= 6f46dc9509b4d10802aaa1ad3c84763a2843312fdc8dd8add5c7b24e7f0c877f
|
||||
SHA2-256(./include/openssl/whrlpool.h)= bb8f9f6ad1960e87f78363793130a0c1bee89b64a12eb32e939791fb0ca61016
|
||||
SHA2-256(./include/openssl/x509.h)= 67508e0a77ef6bb1caf53f8cc018eb1883ded35e65ac9c87c23658a62629c0bb
|
||||
SHA2-256(./include/openssl/x509_vfy.h)= 8f4b78478d697614edad17c08ca34317ccfefd594ec053d444e842aaecebb14d
|
||||
SHA2-256(./include/openssl/x509err.h)= 2c4d4a6f0c94bfc1fc3208f45c50463240719a25de72716d7d033845a84d991e
|
||||
SHA2-256(./include/openssl/x509v3.h)= bf492e29364b57f4f130619b18d2932763e9c3f54024cd4979a84a26e064624d
|
||||
SHA2-256(./include/openssl/x509v3err.h)= 25ce00779ee00002830ede3e302a8b4bf03dbc505243d2b87a86a62c31a52d6f
|
||||
SHA2-256(./include/zconf.h)= e5a9079e37fa799583634fcd6905b53f1c20fd1d98e6bae942674c3c419b9fab
|
||||
SHA2-256(./include/zdict.h)= 02a34169467501fcc665cccb33f5bd455fdb665e9806851777dc8a6c4d5a75e3
|
||||
SHA2-256(./include/zlib.h)= a980a0d104198a53cc220c51ab5856e5be901bec8a2d02e0ee79a8754219dfed
|
||||
SHA2-256(./include/zstd.h)= 41d0f43747d0dee56f60bd10aed262f193d725b7e11eb9e94aa4ad80183c7da8
|
||||
SHA2-256(./include/zstd_errors.h)= 36dbd0a595852e10ff5b52992294f610055b8781101f4634036e05cf7d4bb506
|
||||
SHA2-256(./lib/libbrotlicommon.a)= 63c4c939411bf4d409ce5d3897dda4c2f4c7d380bdc53834680e028634f1e470
|
||||
SHA2-256(./lib/libbrotlidec.a)= 5d22a3d49e3768a66b0ad55c3448092277f64cd85dd37c9e127699b3ccfe5b79
|
||||
SHA2-256(./lib/libcrypto.a)= ce5f64219af5097cc967254e8eb2a828187dc9ecf5e55078301496a5fd090a8c
|
||||
SHA2-256(./lib/libcurl.a)= 9c5226c75751a067715c42dcab690e472132ab44d8c0ab45249c8696c175ec77
|
||||
SHA2-256(./lib/libcurl.dll.a)= 8fe78c9f947e41ad0f5460ea1857a836e4ebee171d0b17d928fde930f652aec6
|
||||
SHA2-256(./lib/libgsasl.a)= 1833de5f30a1e188bf19a67f6cba999d91be956a9e1651643cdb75c80f481a15
|
||||
SHA2-256(./lib/libnghttp2.a)= 3b99de99b5fb74c30650eba5c880746e099f0d6e5e6b25b0f53329c378c12b7b
|
||||
SHA2-256(./lib/libnghttp3.a)= 886167f9e27135a494cd32d3c42e6839f4163cbdf2ce7697a39d5f4757223fab
|
||||
SHA2-256(./lib/libngtcp2.a)= d00bd6f4e65d9374dc8bac4d40b59c97fa193556210fbd8bf13a1f6b253cf6b1
|
||||
SHA2-256(./lib/libngtcp2_crypto_openssl.a)= 65e9eb51c8c867bc9ad6c1dbe836ef854a62b7e6452f522aadd5b8ac35aff4a4
|
||||
SHA2-256(./lib/libssh2.a)= 53a8079360577e007e0f44fe99725eadcdcd15b3a632244f296cfca61719c56e
|
||||
SHA2-256(./lib/libssl.a)= 37879cd8487f34926365397e8bfd794e34c600dd144bb94becd8adfafce1cb6f
|
||||
SHA2-256(./lib/libz.a)= 108bf761dc063ab23e58d248f4b98e53f43bf42a31d63fc324a301d1fd7bc642
|
||||
SHA2-256(./lib/libzstd.a)= 8cf9bc46b060c3374b7c008205fbe572276e77e2c67599139edb461b77255cfa
|
||||
@ -0,0 +1,13 @@
|
||||
.clang 15.0.6
|
||||
.mingw-w64 10.0.0-3
|
||||
zlib 1.2.13 https://zlib.net/zlib-1.2.13.tar.xz
|
||||
zstd 1.5.5 https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-1.5.5.tar.gz
|
||||
brotli 1.0.9 https://github.com/google/brotli/archive/v1.0.9.tar.gz
|
||||
nghttp3 0.10.0 https://github.com/ngtcp2/nghttp3/releases/download/v0.10.0/nghttp3-0.10.0.tar.xz
|
||||
quictls 3.1.0 https://github.com/quictls/openssl/archive/refs/heads/openssl-3.1.0+quic.tar.gz
|
||||
gsasl 2.2.0 https://ftp.gnu.org/gnu/gsasl/gsasl-2.2.0.tar.gz
|
||||
ngtcp2 0.14.1 https://github.com/ngtcp2/ngtcp2/releases/download/v0.14.1/ngtcp2-0.14.1.tar.xz
|
||||
nghttp2 1.53.0 https://github.com/nghttp2/nghttp2/releases/download/v1.53.0/nghttp2-1.53.0.tar.xz
|
||||
libssh2 1.10.0 https://www.libssh2.org/download/libssh2-1.10.0.tar.gz
|
||||
cacert 2023-01-10 https://curl.se/ca/cacert-2023-01-10.pem
|
||||
curl 8.0.1 https://curl.se/download/curl-8.0.1.tar.xz
|
||||
@ -0,0 +1,2 @@
|
||||
[InternetShortcut]
|
||||
URL=https://github.com/curl/curl-for-win
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,22 @@
|
||||
COPYRIGHT AND PERMISSION NOTICE
|
||||
|
||||
Copyright (c) 1996 - 2023, Daniel Stenberg, <daniel@haxx.se>, and many
|
||||
contributors, see the THANKS file.
|
||||
|
||||
All rights reserved.
|
||||
|
||||
Permission to use, copy, modify, and distribute this software for any purpose
|
||||
with or without fee is hereby granted, provided that the above copyright
|
||||
notice and this permission notice appear in all copies.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN
|
||||
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
|
||||
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
|
||||
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
|
||||
OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
Except as contained in this notice, the name of a copyright holder shall not
|
||||
be used in advertising or otherwise to promote the sale, use or other dealings
|
||||
in this Software without prior written authorization of the copyright holder.
|
||||
@ -0,0 +1,55 @@
|
||||
_ _ ____ _
|
||||
___| | | | _ \| |
|
||||
/ __| | | | |_) | |
|
||||
| (__| |_| | _ <| |___
|
||||
\___|\___/|_| \_\_____|
|
||||
|
||||
README
|
||||
|
||||
Curl is a command line tool for transferring data specified with URL
|
||||
syntax. Find out how to use curl by reading the curl.1 man page or the
|
||||
MANUAL document. Find out how to install Curl by reading the INSTALL
|
||||
document.
|
||||
|
||||
libcurl is the library curl is using to do its job. It is readily
|
||||
available to be used by your software. Read the libcurl.3 man page to
|
||||
learn how.
|
||||
|
||||
You find answers to the most frequent questions we get in the FAQ document.
|
||||
|
||||
Study the COPYING file for distribution terms.
|
||||
|
||||
Those documents and more can be found in the docs/ directory.
|
||||
|
||||
CONTACT
|
||||
|
||||
If you have problems, questions, ideas or suggestions, please contact us
|
||||
by posting to a suitable mailing list. See https://curl.se/mail/
|
||||
|
||||
All contributors to the project are listed in the THANKS document.
|
||||
|
||||
WEBSITE
|
||||
|
||||
Visit the curl website for the latest news and downloads:
|
||||
|
||||
https://curl.se/
|
||||
|
||||
GIT
|
||||
|
||||
To download the latest source code off the GIT server, do this:
|
||||
|
||||
git clone https://github.com/curl/curl.git
|
||||
|
||||
(you will get a directory named curl created, filled with the source code)
|
||||
|
||||
SECURITY PROBLEMS
|
||||
|
||||
Report suspected security problems via our HackerOne page and not in public.
|
||||
|
||||
https://hackerone.com/curl
|
||||
|
||||
NOTICE
|
||||
|
||||
Curl contains pieces of source code that is Copyright (c) 1998, 1999
|
||||
Kungliga Tekniska Högskolan. This notice is included here to comply with the
|
||||
distribution terms.
|
||||
@ -0,0 +1,33 @@
|
||||
curl and libcurl 8.0.1
|
||||
|
||||
Public curl releases: 216
|
||||
Command line options: 250
|
||||
curl_easy_setopt() options: 302
|
||||
Public functions in libcurl: 91
|
||||
Contributors: 2841
|
||||
|
||||
This release includes the following bugfixes:
|
||||
|
||||
o Revert "multi: remove PENDING + MSGSENT handles" [1]
|
||||
|
||||
This release includes the following known bugs:
|
||||
|
||||
o see docs/KNOWN_BUGS (https://curl.se/docs/knownbugs.html)
|
||||
|
||||
Planned upcoming removals include:
|
||||
|
||||
o gskit
|
||||
o NSS
|
||||
o support for space-separated NOPROXY patterns
|
||||
o support for the original legacy mingw version 1
|
||||
|
||||
See https://curl.se/dev/deprecate.html for details
|
||||
|
||||
This release would not have looked like this without help, code, reports and
|
||||
advice from friends like these:
|
||||
|
||||
Daniel Stenberg, Kamil Dudka
|
||||
|
||||
References to bug reports and discussions on issues:
|
||||
|
||||
[1] = https://curl.se/bug/?i=10795
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
Двоичный файл не отображается.
@ -0,0 +1,92 @@
|
||||
EXPORTS
|
||||
curl_easy_cleanup @1
|
||||
curl_easy_duphandle @2
|
||||
curl_easy_escape @3
|
||||
curl_easy_getinfo @4
|
||||
curl_easy_header @5
|
||||
curl_easy_init @6
|
||||
curl_easy_nextheader @7
|
||||
curl_easy_option_by_id @8
|
||||
curl_easy_option_by_name @9
|
||||
curl_easy_option_next @10
|
||||
curl_easy_pause @11
|
||||
curl_easy_perform @12
|
||||
curl_easy_recv @13
|
||||
curl_easy_reset @14
|
||||
curl_easy_send @15
|
||||
curl_easy_setopt @16
|
||||
curl_easy_strerror @17
|
||||
curl_easy_unescape @18
|
||||
curl_easy_upkeep @19
|
||||
curl_escape @20
|
||||
curl_formadd @21
|
||||
curl_formfree @22
|
||||
curl_formget @23
|
||||
curl_free @24
|
||||
curl_getdate @25
|
||||
curl_getenv @26
|
||||
curl_global_cleanup @27
|
||||
curl_global_init @28
|
||||
curl_global_init_mem @29
|
||||
curl_global_sslset @30
|
||||
curl_maprintf @31
|
||||
curl_mfprintf @32
|
||||
curl_mime_addpart @33
|
||||
curl_mime_data @34
|
||||
curl_mime_data_cb @35
|
||||
curl_mime_encoder @36
|
||||
curl_mime_filedata @37
|
||||
curl_mime_filename @38
|
||||
curl_mime_free @39
|
||||
curl_mime_headers @40
|
||||
curl_mime_init @41
|
||||
curl_mime_name @42
|
||||
curl_mime_subparts @43
|
||||
curl_mime_type @44
|
||||
curl_mprintf @45
|
||||
curl_msnprintf @46
|
||||
curl_msprintf @47
|
||||
curl_multi_add_handle @48
|
||||
curl_multi_assign @49
|
||||
curl_multi_cleanup @50
|
||||
curl_multi_fdset @51
|
||||
curl_multi_info_read @52
|
||||
curl_multi_init @53
|
||||
curl_multi_perform @54
|
||||
curl_multi_poll @55
|
||||
curl_multi_remove_handle @56
|
||||
curl_multi_setopt @57
|
||||
curl_multi_socket @58
|
||||
curl_multi_socket_action @59
|
||||
curl_multi_socket_all @60
|
||||
curl_multi_strerror @61
|
||||
curl_multi_timeout @62
|
||||
curl_multi_wait @63
|
||||
curl_multi_wakeup @64
|
||||
curl_mvaprintf @65
|
||||
curl_mvfprintf @66
|
||||
curl_mvprintf @67
|
||||
curl_mvsnprintf @68
|
||||
curl_mvsprintf @69
|
||||
curl_pushheader_byname @70
|
||||
curl_pushheader_bynum @71
|
||||
curl_share_cleanup @72
|
||||
curl_share_init @73
|
||||
curl_share_setopt @74
|
||||
curl_share_strerror @75
|
||||
curl_slist_append @76
|
||||
curl_slist_free_all @77
|
||||
curl_strequal @78
|
||||
curl_strnequal @79
|
||||
curl_unescape @80
|
||||
curl_url @81
|
||||
curl_url_cleanup @82
|
||||
curl_url_dup @83
|
||||
curl_url_get @84
|
||||
curl_url_set @85
|
||||
curl_url_strerror @86
|
||||
curl_version @87
|
||||
curl_version_info @88
|
||||
curl_ws_meta @89
|
||||
curl_ws_recv @90
|
||||
curl_ws_send @91
|
||||
Двоичный файл не отображается.
@ -0,0 +1,19 @@
|
||||
Copyright (c) 2009, 2010, 2013-2016 by the Brotli Authors.
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in
|
||||
all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
||||
THE SOFTWARE.
|
||||
@ -0,0 +1,104 @@
|
||||
<p align="center"><img src="https://brotli.org/brotli.svg" alt="Brotli" width="64"></p>
|
||||
|
||||
# SECURITY NOTE
|
||||
|
||||
Please consider updating brotli to version 1.0.9 (latest).
|
||||
|
||||
Version 1.0.9 contains a fix to "integer overflow" problem. This happens when "one-shot" decoding API is used (or input chunk for streaming API is not limited), input size (chunk size) is larger than 2GiB, and input contains uncompressed blocks. After the overflow happens, `memcpy` is invoked with a gigantic `num` value, that will likely cause the crash.
|
||||
|
||||
### Introduction
|
||||
|
||||
Brotli is a generic-purpose lossless compression algorithm that compresses data
|
||||
using a combination of a modern variant of the LZ77 algorithm, Huffman coding
|
||||
and 2nd order context modeling, with a compression ratio comparable to the best
|
||||
currently available general-purpose compression methods. It is similar in speed
|
||||
with deflate but offers more dense compression.
|
||||
|
||||
The specification of the Brotli Compressed Data Format is defined in [RFC 7932](https://tools.ietf.org/html/rfc7932).
|
||||
|
||||
Brotli is open-sourced under the MIT License, see the LICENSE file.
|
||||
|
||||
Brotli mailing list:
|
||||
https://groups.google.com/forum/#!forum/brotli
|
||||
|
||||
[](https://travis-ci.org/google/brotli)
|
||||
[](https://ci.appveyor.com/project/szabadka/brotli)
|
||||
[](https://oss-fuzz-build-logs.storage.googleapis.com/index.html#brotli)
|
||||
|
||||
### Build instructions
|
||||
|
||||
#### Vcpkg
|
||||
|
||||
You can download and install brotli using the [vcpkg](https://github.com/Microsoft/vcpkg/) dependency manager:
|
||||
|
||||
git clone https://github.com/Microsoft/vcpkg.git
|
||||
cd vcpkg
|
||||
./bootstrap-vcpkg.sh
|
||||
./vcpkg integrate install
|
||||
vcpkg install brotli
|
||||
|
||||
The brotli port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please [create an issue or pull request](https://github.com/Microsoft/vcpkg) on the vcpkg repository.
|
||||
|
||||
#### Autotools-style CMake
|
||||
|
||||
[configure-cmake](https://github.com/nemequ/configure-cmake) is an
|
||||
autotools-style configure script for CMake-based projects (not supported on Windows).
|
||||
|
||||
The basic commands to build, test and install brotli are:
|
||||
|
||||
$ mkdir out && cd out
|
||||
$ ../configure-cmake
|
||||
$ make
|
||||
$ make test
|
||||
$ make install
|
||||
|
||||
By default, debug binaries are built. To generate "release" `Makefile` specify `--disable-debug` option to `configure-cmake`.
|
||||
|
||||
#### Bazel
|
||||
|
||||
See [Bazel](http://www.bazel.build/)
|
||||
|
||||
#### CMake
|
||||
|
||||
The basic commands to build and install brotli are:
|
||||
|
||||
$ mkdir out && cd out
|
||||
$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=./installed ..
|
||||
$ cmake --build . --config Release --target install
|
||||
|
||||
You can use other [CMake](https://cmake.org/) configuration.
|
||||
|
||||
#### Premake5
|
||||
|
||||
See [Premake5](https://premake.github.io/)
|
||||
|
||||
#### Python
|
||||
|
||||
To install the latest release of the Python module, run the following:
|
||||
|
||||
$ pip install brotli
|
||||
|
||||
To install the tip-of-the-tree version, run:
|
||||
|
||||
$ pip install --upgrade git+https://github.com/google/brotli
|
||||
|
||||
See the [Python readme](python/README.md) for more details on installing
|
||||
from source, development, and testing.
|
||||
|
||||
### Benchmarks
|
||||
* [Squash Compression Benchmark](https://quixdb.github.io/squash-benchmark/) / [Unstable Squash Compression Benchmark](https://quixdb.github.io/squash-benchmark/unstable/)
|
||||
* [Large Text Compression Benchmark](http://mattmahoney.net/dc/text.html)
|
||||
* [Lzturbo Benchmark](https://sites.google.com/site/powturbo/home/benchmark)
|
||||
|
||||
### Related projects
|
||||
> **Disclaimer:** Brotli authors take no responsibility for the third party projects mentioned in this section.
|
||||
|
||||
Independent [decoder](https://github.com/madler/brotli) implementation by Mark Adler, based entirely on format specification.
|
||||
|
||||
JavaScript port of brotli [decoder](https://github.com/devongovett/brotli.js). Could be used directly via `npm install brotli`
|
||||
|
||||
Hand ported [decoder / encoder](https://github.com/dominikhlbg/BrotliHaxe) in haxe by Dominik Homberger. Output source code: JavaScript, PHP, Python, Java and C#
|
||||
|
||||
7Zip [plugin](https://github.com/mcmilk/7-Zip-Zstd)
|
||||
|
||||
Dart [native bindings](https://github.com/thosakwe/brotli)
|
||||
@ -0,0 +1,2 @@
|
||||
[InternetShortcut]
|
||||
URL=https://www.mozilla.org/media/MPL/2.0/index.txt
|
||||
@ -0,0 +1,20 @@
|
||||
GNU SASL AUTHORS -- Information about the authors.
|
||||
Copyright (C) 2002-2022 Simon Josefsson
|
||||
See the end for copying conditions.
|
||||
|
||||
Simon Josefsson <simon@josefsson.org>
|
||||
Designed and implemented GNU SASL.
|
||||
|
||||
Dirk Armand Marcel Dierckx <dirk.dierckx@solidity.org>
|
||||
Implemented gsasl_client/server_suggest_mechanism.
|
||||
|
||||
James Canete <jcanete01@shaw.ca>
|
||||
Fixed digest-md5 to not add excessive commas.
|
||||
|
||||
Adam Strzelecki <ono@java.pl>
|
||||
Contributed Windows Visual Studio project files.
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Copying and distribution of this file, with or without modification,
|
||||
are permitted in any medium without royalty provided the copyright
|
||||
notice and this notice are preserved.
|
||||
@ -0,0 +1,674 @@
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 3, 29 June 2007
|
||||
|
||||
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The GNU General Public License is a free, copyleft license for
|
||||
software and other kinds of works.
|
||||
|
||||
The licenses for most software and other practical works are designed
|
||||
to take away your freedom to share and change the works. By contrast,
|
||||
the GNU General Public License is intended to guarantee your freedom to
|
||||
share and change all versions of a program--to make sure it remains free
|
||||
software for all its users. We, the Free Software Foundation, use the
|
||||
GNU General Public License for most of our software; it applies also to
|
||||
any other work released this way by its authors. You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
them if you wish), that you receive source code or can get it if you
|
||||
want it, that you can change the software or use pieces of it in new
|
||||
free programs, and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to prevent others from denying you
|
||||
these rights or asking you to surrender the rights. Therefore, you have
|
||||
certain responsibilities if you distribute copies of the software, or if
|
||||
you modify it: responsibilities to respect the freedom of others.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must pass on to the recipients the same
|
||||
freedoms that you received. You must make sure that they, too, receive
|
||||
or can get the source code. And you must show them these terms so they
|
||||
know their rights.
|
||||
|
||||
Developers that use the GNU GPL protect your rights with two steps:
|
||||
(1) assert copyright on the software, and (2) offer you this License
|
||||
giving you legal permission to copy, distribute and/or modify it.
|
||||
|
||||
For the developers' and authors' protection, the GPL clearly explains
|
||||
that there is no warranty for this free software. For both users' and
|
||||
authors' sake, the GPL requires that modified versions be marked as
|
||||
changed, so that their problems will not be attributed erroneously to
|
||||
authors of previous versions.
|
||||
|
||||
Some devices are designed to deny users access to install or run
|
||||
modified versions of the software inside them, although the manufacturer
|
||||
can do so. This is fundamentally incompatible with the aim of
|
||||
protecting users' freedom to change the software. The systematic
|
||||
pattern of such abuse occurs in the area of products for individuals to
|
||||
use, which is precisely where it is most unacceptable. Therefore, we
|
||||
have designed this version of the GPL to prohibit the practice for those
|
||||
products. If such problems arise substantially in other domains, we
|
||||
stand ready to extend this provision to those domains in future versions
|
||||
of the GPL, as needed to protect the freedom of users.
|
||||
|
||||
Finally, every program is threatened constantly by software patents.
|
||||
States should not allow patents to restrict development and use of
|
||||
software on general-purpose computers, but in those that do, we wish to
|
||||
avoid the special danger that patents applied to a free program could
|
||||
make it effectively proprietary. To prevent this, the GPL assures that
|
||||
patents cannot be used to render the program non-free.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
TERMS AND CONDITIONS
|
||||
|
||||
0. Definitions.
|
||||
|
||||
"This License" refers to version 3 of the GNU General Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds of
|
||||
works, such as semiconductor masks.
|
||||
|
||||
"The Program" refers to any copyrightable work licensed under this
|
||||
License. Each licensee is addressed as "you". "Licensees" and
|
||||
"recipients" may be individuals or organizations.
|
||||
|
||||
To "modify" a work means to copy from or adapt all or part of the work
|
||||
in a fashion requiring copyright permission, other than the making of an
|
||||
exact copy. The resulting work is called a "modified version" of the
|
||||
earlier work or a work "based on" the earlier work.
|
||||
|
||||
A "covered work" means either the unmodified Program or a work based
|
||||
on the Program.
|
||||
|
||||
To "propagate" a work means to do anything with it that, without
|
||||
permission, would make you directly or secondarily liable for
|
||||
infringement under applicable copyright law, except executing it on a
|
||||
computer or modifying a private copy. Propagation includes copying,
|
||||
distribution (with or without modification), making available to the
|
||||
public, and in some countries other activities as well.
|
||||
|
||||
To "convey" a work means any kind of propagation that enables other
|
||||
parties to make or receive copies. Mere interaction with a user through
|
||||
a computer network, with no transfer of a copy, is not conveying.
|
||||
|
||||
An interactive user interface displays "Appropriate Legal Notices"
|
||||
to the extent that it includes a convenient and prominently visible
|
||||
feature that (1) displays an appropriate copyright notice, and (2)
|
||||
tells the user that there is no warranty for the work (except to the
|
||||
extent that warranties are provided), that licensees may convey the
|
||||
work under this License, and how to view a copy of this License. If
|
||||
the interface presents a list of user commands or options, such as a
|
||||
menu, a prominent item in the list meets this criterion.
|
||||
|
||||
1. Source Code.
|
||||
|
||||
The "source code" for a work means the preferred form of the work
|
||||
for making modifications to it. "Object code" means any non-source
|
||||
form of a work.
|
||||
|
||||
A "Standard Interface" means an interface that either is an official
|
||||
standard defined by a recognized standards body, or, in the case of
|
||||
interfaces specified for a particular programming language, one that
|
||||
is widely used among developers working in that language.
|
||||
|
||||
The "System Libraries" of an executable work include anything, other
|
||||
than the work as a whole, that (a) is included in the normal form of
|
||||
packaging a Major Component, but which is not part of that Major
|
||||
Component, and (b) serves only to enable use of the work with that
|
||||
Major Component, or to implement a Standard Interface for which an
|
||||
implementation is available to the public in source code form. A
|
||||
"Major Component", in this context, means a major essential component
|
||||
(kernel, window system, and so on) of the specific operating system
|
||||
(if any) on which the executable work runs, or a compiler used to
|
||||
produce the work, or an object code interpreter used to run it.
|
||||
|
||||
The "Corresponding Source" for a work in object code form means all
|
||||
the source code needed to generate, install, and (for an executable
|
||||
work) run the object code and to modify the work, including scripts to
|
||||
control those activities. However, it does not include the work's
|
||||
System Libraries, or general-purpose tools or generally available free
|
||||
programs which are used unmodified in performing those activities but
|
||||
which are not part of the work. For example, Corresponding Source
|
||||
includes interface definition files associated with source files for
|
||||
the work, and the source code for shared libraries and dynamically
|
||||
linked subprograms that the work is specifically designed to require,
|
||||
such as by intimate data communication or control flow between those
|
||||
subprograms and other parts of the work.
|
||||
|
||||
The Corresponding Source need not include anything that users
|
||||
can regenerate automatically from other parts of the Corresponding
|
||||
Source.
|
||||
|
||||
The Corresponding Source for a work in source code form is that
|
||||
same work.
|
||||
|
||||
2. Basic Permissions.
|
||||
|
||||
All rights granted under this License are granted for the term of
|
||||
copyright on the Program, and are irrevocable provided the stated
|
||||
conditions are met. This License explicitly affirms your unlimited
|
||||
permission to run the unmodified Program. The output from running a
|
||||
covered work is covered by this License only if the output, given its
|
||||
content, constitutes a covered work. This License acknowledges your
|
||||
rights of fair use or other equivalent, as provided by copyright law.
|
||||
|
||||
You may make, run and propagate covered works that you do not
|
||||
convey, without conditions so long as your license otherwise remains
|
||||
in force. You may convey covered works to others for the sole purpose
|
||||
of having them make modifications exclusively for you, or provide you
|
||||
with facilities for running those works, provided that you comply with
|
||||
the terms of this License in conveying all material for which you do
|
||||
not control copyright. Those thus making or running the covered works
|
||||
for you must do so exclusively on your behalf, under your direction
|
||||
and control, on terms that prohibit them from making any copies of
|
||||
your copyrighted material outside their relationship with you.
|
||||
|
||||
Conveying under any other circumstances is permitted solely under
|
||||
the conditions stated below. Sublicensing is not allowed; section 10
|
||||
makes it unnecessary.
|
||||
|
||||
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
|
||||
|
||||
No covered work shall be deemed part of an effective technological
|
||||
measure under any applicable law fulfilling obligations under article
|
||||
11 of the WIPO copyright treaty adopted on 20 December 1996, or
|
||||
similar laws prohibiting or restricting circumvention of such
|
||||
measures.
|
||||
|
||||
When you convey a covered work, you waive any legal power to forbid
|
||||
circumvention of technological measures to the extent such circumvention
|
||||
is effected by exercising rights under this License with respect to
|
||||
the covered work, and you disclaim any intention to limit operation or
|
||||
modification of the work as a means of enforcing, against the work's
|
||||
users, your or third parties' legal rights to forbid circumvention of
|
||||
technological measures.
|
||||
|
||||
4. Conveying Verbatim Copies.
|
||||
|
||||
You may convey verbatim copies of the Program's source code as you
|
||||
receive it, in any medium, provided that you conspicuously and
|
||||
appropriately publish on each copy an appropriate copyright notice;
|
||||
keep intact all notices stating that this License and any
|
||||
non-permissive terms added in accord with section 7 apply to the code;
|
||||
keep intact all notices of the absence of any warranty; and give all
|
||||
recipients a copy of this License along with the Program.
|
||||
|
||||
You may charge any price or no price for each copy that you convey,
|
||||
and you may offer support or warranty protection for a fee.
|
||||
|
||||
5. Conveying Modified Source Versions.
|
||||
|
||||
You may convey a work based on the Program, or the modifications to
|
||||
produce it from the Program, in the form of source code under the
|
||||
terms of section 4, provided that you also meet all of these conditions:
|
||||
|
||||
a) The work must carry prominent notices stating that you modified
|
||||
it, and giving a relevant date.
|
||||
|
||||
b) The work must carry prominent notices stating that it is
|
||||
released under this License and any conditions added under section
|
||||
7. This requirement modifies the requirement in section 4 to
|
||||
"keep intact all notices".
|
||||
|
||||
c) You must license the entire work, as a whole, under this
|
||||
License to anyone who comes into possession of a copy. This
|
||||
License will therefore apply, along with any applicable section 7
|
||||
additional terms, to the whole of the work, and all its parts,
|
||||
regardless of how they are packaged. This License gives no
|
||||
permission to license the work in any other way, but it does not
|
||||
invalidate such permission if you have separately received it.
|
||||
|
||||
d) If the work has interactive user interfaces, each must display
|
||||
Appropriate Legal Notices; however, if the Program has interactive
|
||||
interfaces that do not display Appropriate Legal Notices, your
|
||||
work need not make them do so.
|
||||
|
||||
A compilation of a covered work with other separate and independent
|
||||
works, which are not by their nature extensions of the covered work,
|
||||
and which are not combined with it such as to form a larger program,
|
||||
in or on a volume of a storage or distribution medium, is called an
|
||||
"aggregate" if the compilation and its resulting copyright are not
|
||||
used to limit the access or legal rights of the compilation's users
|
||||
beyond what the individual works permit. Inclusion of a covered work
|
||||
in an aggregate does not cause this License to apply to the other
|
||||
parts of the aggregate.
|
||||
|
||||
6. Conveying Non-Source Forms.
|
||||
|
||||
You may convey a covered work in object code form under the terms
|
||||
of sections 4 and 5, provided that you also convey the
|
||||
machine-readable Corresponding Source under the terms of this License,
|
||||
in one of these ways:
|
||||
|
||||
a) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by the
|
||||
Corresponding Source fixed on a durable physical medium
|
||||
customarily used for software interchange.
|
||||
|
||||
b) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by a
|
||||
written offer, valid for at least three years and valid for as
|
||||
long as you offer spare parts or customer support for that product
|
||||
model, to give anyone who possesses the object code either (1) a
|
||||
copy of the Corresponding Source for all the software in the
|
||||
product that is covered by this License, on a durable physical
|
||||
medium customarily used for software interchange, for a price no
|
||||
more than your reasonable cost of physically performing this
|
||||
conveying of source, or (2) access to copy the
|
||||
Corresponding Source from a network server at no charge.
|
||||
|
||||
c) Convey individual copies of the object code with a copy of the
|
||||
written offer to provide the Corresponding Source. This
|
||||
alternative is allowed only occasionally and noncommercially, and
|
||||
only if you received the object code with such an offer, in accord
|
||||
with subsection 6b.
|
||||
|
||||
d) Convey the object code by offering access from a designated
|
||||
place (gratis or for a charge), and offer equivalent access to the
|
||||
Corresponding Source in the same way through the same place at no
|
||||
further charge. You need not require recipients to copy the
|
||||
Corresponding Source along with the object code. If the place to
|
||||
copy the object code is a network server, the Corresponding Source
|
||||
may be on a different server (operated by you or a third party)
|
||||
that supports equivalent copying facilities, provided you maintain
|
||||
clear directions next to the object code saying where to find the
|
||||
Corresponding Source. Regardless of what server hosts the
|
||||
Corresponding Source, you remain obligated to ensure that it is
|
||||
available for as long as needed to satisfy these requirements.
|
||||
|
||||
e) Convey the object code using peer-to-peer transmission, provided
|
||||
you inform other peers where the object code and Corresponding
|
||||
Source of the work are being offered to the general public at no
|
||||
charge under subsection 6d.
|
||||
|
||||
A separable portion of the object code, whose source code is excluded
|
||||
from the Corresponding Source as a System Library, need not be
|
||||
included in conveying the object code work.
|
||||
|
||||
A "User Product" is either (1) a "consumer product", which means any
|
||||
tangible personal property which is normally used for personal, family,
|
||||
or household purposes, or (2) anything designed or sold for incorporation
|
||||
into a dwelling. In determining whether a product is a consumer product,
|
||||
doubtful cases shall be resolved in favor of coverage. For a particular
|
||||
product received by a particular user, "normally used" refers to a
|
||||
typical or common use of that class of product, regardless of the status
|
||||
of the particular user or of the way in which the particular user
|
||||
actually uses, or expects or is expected to use, the product. A product
|
||||
is a consumer product regardless of whether the product has substantial
|
||||
commercial, industrial or non-consumer uses, unless such uses represent
|
||||
the only significant mode of use of the product.
|
||||
|
||||
"Installation Information" for a User Product means any methods,
|
||||
procedures, authorization keys, or other information required to install
|
||||
and execute modified versions of a covered work in that User Product from
|
||||
a modified version of its Corresponding Source. The information must
|
||||
suffice to ensure that the continued functioning of the modified object
|
||||
code is in no case prevented or interfered with solely because
|
||||
modification has been made.
|
||||
|
||||
If you convey an object code work under this section in, or with, or
|
||||
specifically for use in, a User Product, and the conveying occurs as
|
||||
part of a transaction in which the right of possession and use of the
|
||||
User Product is transferred to the recipient in perpetuity or for a
|
||||
fixed term (regardless of how the transaction is characterized), the
|
||||
Corresponding Source conveyed under this section must be accompanied
|
||||
by the Installation Information. But this requirement does not apply
|
||||
if neither you nor any third party retains the ability to install
|
||||
modified object code on the User Product (for example, the work has
|
||||
been installed in ROM).
|
||||
|
||||
The requirement to provide Installation Information does not include a
|
||||
requirement to continue to provide support service, warranty, or updates
|
||||
for a work that has been modified or installed by the recipient, or for
|
||||
the User Product in which it has been modified or installed. Access to a
|
||||
network may be denied when the modification itself materially and
|
||||
adversely affects the operation of the network or violates the rules and
|
||||
protocols for communication across the network.
|
||||
|
||||
Corresponding Source conveyed, and Installation Information provided,
|
||||
in accord with this section must be in a format that is publicly
|
||||
documented (and with an implementation available to the public in
|
||||
source code form), and must require no special password or key for
|
||||
unpacking, reading or copying.
|
||||
|
||||
7. Additional Terms.
|
||||
|
||||
"Additional permissions" are terms that supplement the terms of this
|
||||
License by making exceptions from one or more of its conditions.
|
||||
Additional permissions that are applicable to the entire Program shall
|
||||
be treated as though they were included in this License, to the extent
|
||||
that they are valid under applicable law. If additional permissions
|
||||
apply only to part of the Program, that part may be used separately
|
||||
under those permissions, but the entire Program remains governed by
|
||||
this License without regard to the additional permissions.
|
||||
|
||||
When you convey a copy of a covered work, you may at your option
|
||||
remove any additional permissions from that copy, or from any part of
|
||||
it. (Additional permissions may be written to require their own
|
||||
removal in certain cases when you modify the work.) You may place
|
||||
additional permissions on material, added by you to a covered work,
|
||||
for which you have or can give appropriate copyright permission.
|
||||
|
||||
Notwithstanding any other provision of this License, for material you
|
||||
add to a covered work, you may (if authorized by the copyright holders of
|
||||
that material) supplement the terms of this License with terms:
|
||||
|
||||
a) Disclaiming warranty or limiting liability differently from the
|
||||
terms of sections 15 and 16 of this License; or
|
||||
|
||||
b) Requiring preservation of specified reasonable legal notices or
|
||||
author attributions in that material or in the Appropriate Legal
|
||||
Notices displayed by works containing it; or
|
||||
|
||||
c) Prohibiting misrepresentation of the origin of that material, or
|
||||
requiring that modified versions of such material be marked in
|
||||
reasonable ways as different from the original version; or
|
||||
|
||||
d) Limiting the use for publicity purposes of names of licensors or
|
||||
authors of the material; or
|
||||
|
||||
e) Declining to grant rights under trademark law for use of some
|
||||
trade names, trademarks, or service marks; or
|
||||
|
||||
f) Requiring indemnification of licensors and authors of that
|
||||
material by anyone who conveys the material (or modified versions of
|
||||
it) with contractual assumptions of liability to the recipient, for
|
||||
any liability that these contractual assumptions directly impose on
|
||||
those licensors and authors.
|
||||
|
||||
All other non-permissive additional terms are considered "further
|
||||
restrictions" within the meaning of section 10. If the Program as you
|
||||
received it, or any part of it, contains a notice stating that it is
|
||||
governed by this License along with a term that is a further
|
||||
restriction, you may remove that term. If a license document contains
|
||||
a further restriction but permits relicensing or conveying under this
|
||||
License, you may add to a covered work material governed by the terms
|
||||
of that license document, provided that the further restriction does
|
||||
not survive such relicensing or conveying.
|
||||
|
||||
If you add terms to a covered work in accord with this section, you
|
||||
must place, in the relevant source files, a statement of the
|
||||
additional terms that apply to those files, or a notice indicating
|
||||
where to find the applicable terms.
|
||||
|
||||
Additional terms, permissive or non-permissive, may be stated in the
|
||||
form of a separately written license, or stated as exceptions;
|
||||
the above requirements apply either way.
|
||||
|
||||
8. Termination.
|
||||
|
||||
You may not propagate or modify a covered work except as expressly
|
||||
provided under this License. Any attempt otherwise to propagate or
|
||||
modify it is void, and will automatically terminate your rights under
|
||||
this License (including any patent licenses granted under the third
|
||||
paragraph of section 11).
|
||||
|
||||
However, if you cease all violation of this License, then your
|
||||
license from a particular copyright holder is reinstated (a)
|
||||
provisionally, unless and until the copyright holder explicitly and
|
||||
finally terminates your license, and (b) permanently, if the copyright
|
||||
holder fails to notify you of the violation by some reasonable means
|
||||
prior to 60 days after the cessation.
|
||||
|
||||
Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, you do not qualify to receive new licenses for the same
|
||||
material under section 10.
|
||||
|
||||
9. Acceptance Not Required for Having Copies.
|
||||
|
||||
You are not required to accept this License in order to receive or
|
||||
run a copy of the Program. Ancillary propagation of a covered work
|
||||
occurring solely as a consequence of using peer-to-peer transmission
|
||||
to receive a copy likewise does not require acceptance. However,
|
||||
nothing other than this License grants you permission to propagate or
|
||||
modify any covered work. These actions infringe copyright if you do
|
||||
not accept this License. Therefore, by modifying or propagating a
|
||||
covered work, you indicate your acceptance of this License to do so.
|
||||
|
||||
10. Automatic Licensing of Downstream Recipients.
|
||||
|
||||
Each time you convey a covered work, the recipient automatically
|
||||
receives a license from the original licensors, to run, modify and
|
||||
propagate that work, subject to this License. You are not responsible
|
||||
for enforcing compliance by third parties with this License.
|
||||
|
||||
An "entity transaction" is a transaction transferring control of an
|
||||
organization, or substantially all assets of one, or subdividing an
|
||||
organization, or merging organizations. If propagation of a covered
|
||||
work results from an entity transaction, each party to that
|
||||
transaction who receives a copy of the work also receives whatever
|
||||
licenses to the work the party's predecessor in interest had or could
|
||||
give under the previous paragraph, plus a right to possession of the
|
||||
Corresponding Source of the work from the predecessor in interest, if
|
||||
the predecessor has it or can get it with reasonable efforts.
|
||||
|
||||
You may not impose any further restrictions on the exercise of the
|
||||
rights granted or affirmed under this License. For example, you may
|
||||
not impose a license fee, royalty, or other charge for exercise of
|
||||
rights granted under this License, and you may not initiate litigation
|
||||
(including a cross-claim or counterclaim in a lawsuit) alleging that
|
||||
any patent claim is infringed by making, using, selling, offering for
|
||||
sale, or importing the Program or any portion of it.
|
||||
|
||||
11. Patents.
|
||||
|
||||
A "contributor" is a copyright holder who authorizes use under this
|
||||
License of the Program or a work on which the Program is based. The
|
||||
work thus licensed is called the contributor's "contributor version".
|
||||
|
||||
A contributor's "essential patent claims" are all patent claims
|
||||
owned or controlled by the contributor, whether already acquired or
|
||||
hereafter acquired, that would be infringed by some manner, permitted
|
||||
by this License, of making, using, or selling its contributor version,
|
||||
but do not include claims that would be infringed only as a
|
||||
consequence of further modification of the contributor version. For
|
||||
purposes of this definition, "control" includes the right to grant
|
||||
patent sublicenses in a manner consistent with the requirements of
|
||||
this License.
|
||||
|
||||
Each contributor grants you a non-exclusive, worldwide, royalty-free
|
||||
patent license under the contributor's essential patent claims, to
|
||||
make, use, sell, offer for sale, import and otherwise run, modify and
|
||||
propagate the contents of its contributor version.
|
||||
|
||||
In the following three paragraphs, a "patent license" is any express
|
||||
agreement or commitment, however denominated, not to enforce a patent
|
||||
(such as an express permission to practice a patent or covenant not to
|
||||
sue for patent infringement). To "grant" such a patent license to a
|
||||
party means to make such an agreement or commitment not to enforce a
|
||||
patent against the party.
|
||||
|
||||
If you convey a covered work, knowingly relying on a patent license,
|
||||
and the Corresponding Source of the work is not available for anyone
|
||||
to copy, free of charge and under the terms of this License, through a
|
||||
publicly available network server or other readily accessible means,
|
||||
then you must either (1) cause the Corresponding Source to be so
|
||||
available, or (2) arrange to deprive yourself of the benefit of the
|
||||
patent license for this particular work, or (3) arrange, in a manner
|
||||
consistent with the requirements of this License, to extend the patent
|
||||
license to downstream recipients. "Knowingly relying" means you have
|
||||
actual knowledge that, but for the patent license, your conveying the
|
||||
covered work in a country, or your recipient's use of the covered work
|
||||
in a country, would infringe one or more identifiable patents in that
|
||||
country that you have reason to believe are valid.
|
||||
|
||||
If, pursuant to or in connection with a single transaction or
|
||||
arrangement, you convey, or propagate by procuring conveyance of, a
|
||||
covered work, and grant a patent license to some of the parties
|
||||
receiving the covered work authorizing them to use, propagate, modify
|
||||
or convey a specific copy of the covered work, then the patent license
|
||||
you grant is automatically extended to all recipients of the covered
|
||||
work and works based on it.
|
||||
|
||||
A patent license is "discriminatory" if it does not include within
|
||||
the scope of its coverage, prohibits the exercise of, or is
|
||||
conditioned on the non-exercise of one or more of the rights that are
|
||||
specifically granted under this License. You may not convey a covered
|
||||
work if you are a party to an arrangement with a third party that is
|
||||
in the business of distributing software, under which you make payment
|
||||
to the third party based on the extent of your activity of conveying
|
||||
the work, and under which the third party grants, to any of the
|
||||
parties who would receive the covered work from you, a discriminatory
|
||||
patent license (a) in connection with copies of the covered work
|
||||
conveyed by you (or copies made from those copies), or (b) primarily
|
||||
for and in connection with specific products or compilations that
|
||||
contain the covered work, unless you entered into that arrangement,
|
||||
or that patent license was granted, prior to 28 March 2007.
|
||||
|
||||
Nothing in this License shall be construed as excluding or limiting
|
||||
any implied license or other defenses to infringement that may
|
||||
otherwise be available to you under applicable patent law.
|
||||
|
||||
12. No Surrender of Others' Freedom.
|
||||
|
||||
If conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot convey a
|
||||
covered work so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you may
|
||||
not convey it at all. For example, if you agree to terms that obligate you
|
||||
to collect a royalty for further conveying from those to whom you convey
|
||||
the Program, the only way you could satisfy both those terms and this
|
||||
License would be to refrain entirely from conveying the Program.
|
||||
|
||||
13. Use with the GNU Affero General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, you have
|
||||
permission to link or combine any covered work with a work licensed
|
||||
under version 3 of the GNU Affero General Public License into a single
|
||||
combined work, and to convey the resulting work. The terms of this
|
||||
License will continue to apply to the part which is the covered work,
|
||||
but the special requirements of the GNU Affero General Public License,
|
||||
section 13, concerning interaction through a network will apply to the
|
||||
combination as such.
|
||||
|
||||
14. Revised Versions of this License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions of
|
||||
the GNU General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies that a certain numbered version of the GNU General
|
||||
Public License "or any later version" applies to it, you have the
|
||||
option of following the terms and conditions either of that numbered
|
||||
version or of any later version published by the Free Software
|
||||
Foundation. If the Program does not specify a version number of the
|
||||
GNU General Public License, you may choose any version ever published
|
||||
by the Free Software Foundation.
|
||||
|
||||
If the Program specifies that a proxy can decide which future
|
||||
versions of the GNU General Public License can be used, that proxy's
|
||||
public statement of acceptance of a version permanently authorizes you
|
||||
to choose that version for the Program.
|
||||
|
||||
Later license versions may give you additional or different
|
||||
permissions. However, no additional obligations are imposed on any
|
||||
author or copyright holder as a result of your choosing to follow a
|
||||
later version.
|
||||
|
||||
15. Disclaimer of Warranty.
|
||||
|
||||
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
|
||||
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
|
||||
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
|
||||
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
|
||||
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
|
||||
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
16. Limitation of Liability.
|
||||
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
|
||||
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
|
||||
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
|
||||
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
|
||||
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
|
||||
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
|
||||
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
|
||||
SUCH DAMAGES.
|
||||
|
||||
17. Interpretation of Sections 15 and 16.
|
||||
|
||||
If the disclaimer of warranty and limitation of liability provided
|
||||
above cannot be given local legal effect according to their terms,
|
||||
reviewing courts shall apply local law that most closely approximates
|
||||
an absolute waiver of all civil liability in connection with the
|
||||
Program, unless a warranty or assumption of liability accompanies a
|
||||
copy of the Program in return for a fee.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
state the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program does terminal interaction, make it output a short
|
||||
notice like this when it starts in an interactive mode:
|
||||
|
||||
<program> Copyright (C) <year> <name of author>
|
||||
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, your program's commands
|
||||
might be different; for a GUI interface, you would use an "about box".
|
||||
|
||||
You should also get your employer (if you work as a programmer) or school,
|
||||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU GPL, see
|
||||
<https://www.gnu.org/licenses/>.
|
||||
|
||||
The GNU General Public License does not permit incorporating your program
|
||||
into proprietary programs. If your program is a subroutine library, you
|
||||
may consider it more useful to permit linking proprietary applications with
|
||||
the library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License. But first, please read
|
||||
<https://www.gnu.org/licenses/why-not-lgpl.html>.
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,75 @@
|
||||
# GNU SASL README -- Important introductory notes.
|
||||
|
||||
GNU SASL is an implementation of the Simple Authentication and
|
||||
Security Layer (SASL) framework and a few common SASL mechanisms.
|
||||
SASL is used by network servers (e.g., IMAP, SMTP, XMPP) to request
|
||||
authentication from clients, and in clients to authenticate against
|
||||
servers.
|
||||
|
||||
GNU SASL consists of a C library (libgsasl), a command-line
|
||||
application (gsasl), and a manual. The library supports the
|
||||
ANONYMOUS, CRAM-MD5, DIGEST-MD5, EXTERNAL, GS2-KRB5, GSSAPI, LOGIN,
|
||||
NTLM, OPENID20, PLAIN, SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA-256,
|
||||
SCRAM-SHA-256-PLUS, SAML20, and SECURID mechanisms.
|
||||
|
||||
The library is widely portable to any C89 platform. The command-line
|
||||
application requires POSIX or Windows for network communication.
|
||||
|
||||
The [GNU SASL web page](https://www.gnu.org/software/gsasl/) provides
|
||||
current information about the project.
|
||||
|
||||
# License
|
||||
|
||||
The GNU SASL Library (lib/) is licensed under the GNU Lesser General
|
||||
Public License (LGPL) version 2.1 (or later). See the file
|
||||
COPYING.LIB. The GNU project typically uses the GNU General Public
|
||||
License (GPL) for libraries, and not the LGPL, but for this project we
|
||||
decided that we would get more help from the community if we used the
|
||||
LGPLv2.1+, as other free SASL implementations exists. See also
|
||||
<https://www.gnu.org/licenses/why-not-lgpl.html>.
|
||||
|
||||
The command-line application and test suite (src/ and tests/) are
|
||||
licensed under the GNU General Public License license version 3.0 (or
|
||||
later). See the file COPYING.
|
||||
|
||||
The documentation (doc/) is licensed under the GNU Free Documentation
|
||||
License version 1.3 (or later). See the file doc/fdl-1.3.texi.
|
||||
|
||||
For any copyright year range specified as YYYY-ZZZZ in this package
|
||||
note that the range specifies every single year in that closed
|
||||
interval.
|
||||
|
||||
# Support
|
||||
|
||||
If you need help to use GNU SASL, or wish to help others, you are
|
||||
invited to join our mailing list help-gsasl@gnu.org, see
|
||||
<https://lists.gnu.org/mailman/listinfo/help-gsasl>.
|
||||
|
||||
Things left to do below. If you like to start working on anything,
|
||||
please let me know so work duplication can be avoided.
|
||||
|
||||
* Support channel bindings in GS2.
|
||||
* Authentication infrastructure implementing the callbacks for PAM,
|
||||
Kerberos, SQL, etc. Separate project? GNU Mailutils has some
|
||||
starting points for this, but the API is inflexible.
|
||||
* Provide standard callbacks for tty, GTK, gpg-agent etc. Probably
|
||||
should be a separate library.
|
||||
* Port applications to use libgsasl
|
||||
* Bug: If gsasl_decode is handed a string longer than one SASL token,
|
||||
the remaining data will be discarded. This means if the sender
|
||||
packed two SASL tokens in one network packet, only the first will be
|
||||
seen. The en/de-code functions should buffer the left over data
|
||||
until the next invocation. Later: it isn't clear that people
|
||||
actually need the security layer feature, and it seems better to
|
||||
punt to TLS.
|
||||
* Security layer improvements (e.g., DES and AES in DIGEST-MD5).
|
||||
* Cleanup code, possibly by using some string abstraction library.
|
||||
* Privacy separation (authenticate in one process, pass state to another).
|
||||
* Improve documentation
|
||||
* Port to Cyclone? CCured?
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Copyright (C) 2002-2022 Simon Josefsson
|
||||
Copying and distribution of this file, with or without modification,
|
||||
are permitted in any medium without royalty provided the copyright
|
||||
notice and this notice are preserved.
|
||||
@ -0,0 +1,44 @@
|
||||
/* Copyright (c) 2004-2007 Sara Golemon <sarag@libssh2.org>
|
||||
* Copyright (c) 2005,2006 Mikhail Gusarov <dottedmag@dottedmag.net>
|
||||
* Copyright (c) 2006-2007 The Written Word, Inc.
|
||||
* Copyright (c) 2007 Eli Fant <elifantu@mail.ru>
|
||||
* Copyright (c) 2009-2021 Daniel Stenberg
|
||||
* Copyright (C) 2008, 2009 Simon Josefsson
|
||||
* Copyright (c) 2000 Markus Friedl
|
||||
* Copyright (c) 2015 Microsoft Corp.
|
||||
* All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms,
|
||||
* with or without modification, are permitted provided
|
||||
* that the following conditions are met:
|
||||
*
|
||||
* Redistributions of source code must retain the above
|
||||
* copyright notice, this list of conditions and the
|
||||
* following disclaimer.
|
||||
*
|
||||
* Redistributions in binary form must reproduce the above
|
||||
* copyright notice, this list of conditions and the following
|
||||
* disclaimer in the documentation and/or other materials
|
||||
* provided with the distribution.
|
||||
*
|
||||
* Neither the name of the copyright holder nor the names
|
||||
* of any other contributors may be used to endorse or
|
||||
* promote products derived from this software without
|
||||
* specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
|
||||
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
|
||||
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
||||
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
|
||||
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
||||
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
||||
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
|
||||
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
||||
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
|
||||
* USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
|
||||
* OF SUCH DAMAGE.
|
||||
*/
|
||||
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,19 @@
|
||||
libssh2 - SSH2 library
|
||||
======================
|
||||
|
||||
libssh2 is a library implementing the SSH2 protocol, available under
|
||||
the revised BSD license.
|
||||
|
||||
Web site: https://www.libssh2.org/
|
||||
|
||||
Mailing list: https://cool.haxx.se/mailman/listinfo/libssh2-devel
|
||||
|
||||
License: see COPYING
|
||||
|
||||
Source code: https://github.com/libssh2/libssh2
|
||||
|
||||
Web site source code: https://github.com/libssh2/www
|
||||
|
||||
Installation instructions are in:
|
||||
- docs/INSTALL_CMAKE for CMake
|
||||
- docs/INSTALL_AUTOTOOLS for Autotools
|
||||
@ -0,0 +1,62 @@
|
||||
libssh2 1.10
|
||||
|
||||
This release includes the following enhancements and bugfixes:
|
||||
|
||||
o adds agent forwarding support
|
||||
o adds OpenSSH Agent support on Windows
|
||||
o adds ECDSA key support using the Mbed TLS backend
|
||||
o adds ECDSA cert authentication
|
||||
o adds diffie-hellman-group14-sha256, diffie-hellman-group16-sha512,
|
||||
diffie-hellman-group18-sha512 key exchanges
|
||||
o adds support for PKIX key reading when using ed25519 with OpenSSL
|
||||
o adds support for EWOULDBLOCK on VMS systems
|
||||
o adds support for building with OpenSSL 3
|
||||
o adds support for using FIPS mode in OpenSSL
|
||||
o adds debug symbols when building with MSVC
|
||||
o adds support for building on the 3DS
|
||||
o adds unicode build support on Windows
|
||||
o restores os400 building
|
||||
o increases min, max and opt Diffie Hellman group values
|
||||
o improves portiablity of the make file
|
||||
o improves timeout behavior with 2FA keyboard auth
|
||||
o various improvements to the Wincng backend
|
||||
o fixes reading parital packet replies when using an agent
|
||||
o fixes Diffie Hellman key exchange on Windows 1903+ builds
|
||||
o fixes building tests with older versions of OpenSSL
|
||||
o fixes possible multiple definition warnings
|
||||
o fixes potential cast issues _libssh2_ecdsa_key_get_curve_type()
|
||||
o fixes potential use after free if libssh2_init() is called twice
|
||||
o improved linking when using Mbed TLS
|
||||
o fixes call to libssh2_crypto_exit() if crypto hasn't been initialized
|
||||
o fixes crash when loading public keys with no id
|
||||
o fixes possible out of bounds read when exchanging keys
|
||||
o fixes possible out of bounds read when reading packets
|
||||
o fixes possible out of bounds read when opening an X11 connection
|
||||
o fixes possible out of bounds read when ecdh host keys
|
||||
o fixes possible hang when trying to read a disconnected socket
|
||||
o fixes a crash when using the delayed compression option
|
||||
o fixes read error with large known host entries
|
||||
o fixes various warnings
|
||||
o fixes various small memory leaks
|
||||
o improved error handling, various detailed errors will now be reported
|
||||
o builds are now using OSS-Fuzz
|
||||
o builds now use autoreconf instead of a custom build script
|
||||
o cmake now respects install directory
|
||||
o improved CI backend
|
||||
o updated HACKING-CRYPTO documentation
|
||||
o use markdown file extensions
|
||||
o improved unit tests
|
||||
|
||||
This release would not have looked like this without help, code, reports and
|
||||
advice from friends like these:
|
||||
|
||||
katzer, Orgad Shaneh, mark-i-m, Zenju, axjowa, Thilo Schulz,
|
||||
Etienne Samson, hlefebvre, seba30, Panos, jethrogb, Fabrice Fontaine,
|
||||
Will Cosgrove, Daniel Stenberg, Michael Buckley, Wallace Souza Silva,
|
||||
Romain-Geissler-1A, meierha, Tseng Jun, Thomas Klausner, Brendan Shanks,
|
||||
Harry Sintonen, monnerat, Koutheir Attouchi, Marc Hörsken, yann-morin-1998,
|
||||
Wez Furlong, TDi-jonesds, David Benjamin, Max Dymond, Igor Klevanets,
|
||||
Viktor Szakats, Laurent Stacul, Mstrodl, Gabriel Smith, MarcT512,
|
||||
Paul Capron, teottin, Tor Erik Ottinsen, Brian Inglis
|
||||
|
||||
(40 contributors)
|
||||
@ -0,0 +1,79 @@
|
||||
libssh2 is the result of many friendly people. This list is an attempt to
|
||||
mention all contributors. If we've missed anyone, tell us!
|
||||
|
||||
This list of names is a-z sorted.
|
||||
|
||||
Adam Gobiowski
|
||||
Alexander Holyapin
|
||||
Alexander Lamaison
|
||||
Alfred Gebert
|
||||
Ben Kibbey
|
||||
Bjorn Stenborg
|
||||
Carlo Bramini
|
||||
Cristian Rodríguez
|
||||
Daiki Ueno
|
||||
Dan Casey
|
||||
Dan Fandrich
|
||||
Daniel Stenberg
|
||||
Dave Hayden
|
||||
Dave McCaldon
|
||||
David J Sullivan
|
||||
David Robins
|
||||
Dmitry Smirnov
|
||||
Douglas Masterson
|
||||
Edink Kadribasic
|
||||
Erik Brossler
|
||||
Francois Dupoux
|
||||
Gellule Xg
|
||||
Grubsky Grigory
|
||||
Guenter Knauf
|
||||
Heiner Steven
|
||||
Henrik Nordstrom
|
||||
James Housleys
|
||||
Jasmeet Bagga
|
||||
Jean-Louis Charton
|
||||
Jernej Kovacic
|
||||
Joey Degges
|
||||
John Little
|
||||
Jose Baars
|
||||
Jussi Mononen
|
||||
Kamil Dudka
|
||||
Lars Nordin
|
||||
Mark McPherson
|
||||
Mark Smith
|
||||
Markus Moeller
|
||||
Matt Lilley
|
||||
Matthew Booth
|
||||
Maxime Larocque
|
||||
Mike Protts
|
||||
Mikhail Gusarov
|
||||
Neil Gierman
|
||||
Olivier Hervieu
|
||||
Paul Howarth
|
||||
Paul Querna
|
||||
Paul Veldkamp
|
||||
Peter Krempa
|
||||
Peter O'Gorman
|
||||
Peter Stuge
|
||||
Pierre Joye
|
||||
Rafael Kitover
|
||||
Romain Bondue
|
||||
Sara Golemon
|
||||
Satish Mittal
|
||||
Sean Peterson
|
||||
Selcuk Gueney
|
||||
Simon Hart
|
||||
Simon Josefsson
|
||||
Sofian Brabez
|
||||
Steven Ayre
|
||||
Steven Dake
|
||||
Steven Van Ingelgem
|
||||
TJ Saunders
|
||||
Tommy Lindgren
|
||||
Tor Arntsen
|
||||
Vincent Jaulin
|
||||
Vincent Torri
|
||||
Vlad Grachov
|
||||
Wez Furlong
|
||||
Yang Tse
|
||||
Zl Liu
|
||||
@ -0,0 +1,29 @@
|
||||
|
||||
Creative people have written bindings or interfaces for various environments
|
||||
and programming languages. Using one of these bindings allows you to take
|
||||
advantage of libssh2 directly from within your favourite language.
|
||||
|
||||
The bindings listed below are not part of the libssh2 distribution archives,
|
||||
but must be downloaded and installed separately.
|
||||
|
||||
Cocoa/Objective-C
|
||||
https://github.com/karelia/libssh2_sftp-Cocoa-wrapper
|
||||
|
||||
Haskell
|
||||
FFI bindings - https://hackage.haskell.org/package/libssh2
|
||||
|
||||
Perl
|
||||
Net::SSH2 - https://metacpan.org/pod/Net::SSH2
|
||||
|
||||
PHP
|
||||
ssh2 - https://pecl.php.net/package/ssh2
|
||||
|
||||
Python
|
||||
pylibssh2 - https://pypi.python.org/pypi/pylibssh2
|
||||
|
||||
Python-ctypes
|
||||
|
||||
PySsh2 - https://github.com/gellule/PySsh2
|
||||
|
||||
Ruby
|
||||
libssh2-ruby - https://github.com/mitchellh/libssh2-ruby
|
||||
@ -0,0 +1,902 @@
|
||||
Definitions needed to implement a specific crypto library
|
||||
|
||||
This document offers some hints about implementing a new crypto library
|
||||
interface.
|
||||
|
||||
A crypto library interface consists of at least a header file, defining
|
||||
entities referenced from the libssh2 core modules.
|
||||
Real code implementation (if needed), is left at the implementor's choice.
|
||||
|
||||
This document lists the entities that must/may be defined in the header file.
|
||||
|
||||
Procedures listed as "void" may indeed have a result type: the void indication
|
||||
indicates the libssh2 core modules never use the function result.
|
||||
|
||||
|
||||
0) Build system.
|
||||
|
||||
Adding a crypto backend to the autotools build system (./configure) is easy:
|
||||
|
||||
0.1) Add one new line in configure.ac
|
||||
|
||||
m4_set_add([crypto_backends], [newname])
|
||||
|
||||
This automatically creates a --with-crypto=newname option.
|
||||
|
||||
0.2) Add an m4_case stanza to LIBSSH2_CRYPTO_CHECK in acinclude.m4
|
||||
|
||||
This must check for all required libraries, and if found set and AC_SUBST a
|
||||
variable with the library linking flags. The recommended method is to use
|
||||
LIBSSH2_LIB_HAVE_LINKFLAGS from LIBSSH2_CRYPTO_CHECK, which automatically
|
||||
creates and handles a --with-$newname-prefix option and sets an
|
||||
LTLIBNEWNAME variable on success.
|
||||
|
||||
0.3) Create Makefile.newname.inc in the top-level directory
|
||||
|
||||
This must set CRYPTO_CSOURCES, CRYPTO_HHEADERS and CRYPTO_LTLIBS.
|
||||
Set CRYPTO_CSOURCES and CRYPTO_HHEADERS to the new backend source files
|
||||
and set CRYPTO_LTLIBS to the required library linking parameters, e.g.
|
||||
$(LTLIBNEWNAME) as generated by by LIBSSH2_LIB_HAVE_LINKFLAGS.
|
||||
|
||||
0.4) Add a new block in src/Makefile.am
|
||||
|
||||
if NEWNAME
|
||||
include ../Makefile.newname.inc
|
||||
endif
|
||||
|
||||
|
||||
1) Crypto library initialization/termination.
|
||||
|
||||
void libssh2_crypto_init(void);
|
||||
Initializes the crypto library. May be an empty macro if not needed.
|
||||
|
||||
void libssh2_crypto_exit(void);
|
||||
Terminates the crypto library use. May be an empty macro if not needed.
|
||||
|
||||
|
||||
2) HMAC
|
||||
|
||||
libssh2_hmac_ctx
|
||||
Type of an HMAC computation context. Generally a struct.
|
||||
Used for all hash algorithms.
|
||||
|
||||
void libssh2_hmac_ctx_init(libssh2_hmac_ctx ctx);
|
||||
Initializes the HMAC computation context ctx.
|
||||
Called before setting-up the hash algorithm.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_hmac_update(libssh2_hmac_ctx ctx,
|
||||
const unsigned char *data,
|
||||
int datalen);
|
||||
Continue computation of an HMAC on datalen bytes at data using context ctx.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_hmac_final(libssh2_hmac_ctx ctx,
|
||||
unsigned char output[]);
|
||||
Get the computed HMAC from context ctx into the output buffer. The
|
||||
minimum data buffer size depends on the HMAC hash algorithm.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_hmac_cleanup(libssh2_hmac_ctx *ctx);
|
||||
Releases the HMAC computation context at ctx.
|
||||
|
||||
|
||||
3) Hash algorithms.
|
||||
|
||||
3.1) SHA-1
|
||||
Must always be implemented.
|
||||
|
||||
SHA_DIGEST_LENGTH
|
||||
#define to 20, the SHA-1 digest length.
|
||||
|
||||
libssh2_sha1_ctx
|
||||
Type of an SHA-1 computation context. Generally a struct.
|
||||
|
||||
int libssh2_sha1_init(libssh2_sha1_ctx *x);
|
||||
Initializes the SHA-1 computation context at x.
|
||||
Returns 1 for success and 0 for failure
|
||||
|
||||
void libssh2_sha1_update(libssh2_sha1_ctx ctx,
|
||||
const unsigned char *data,
|
||||
size_t len);
|
||||
Continue computation of SHA-1 on len bytes at data using context ctx.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_sha1_final(libssh2_sha1_ctx ctx,
|
||||
unsigned char output[SHA_DIGEST_LEN]);
|
||||
Get the computed SHA-1 signature from context ctx and store it into the
|
||||
output buffer.
|
||||
Release the context.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_hmac_sha1_init(libssh2_hmac_ctx *ctx,
|
||||
const void *key,
|
||||
int keylen);
|
||||
Setup the HMAC computation context ctx for an HMAC-SHA-1 computation using the
|
||||
keylen-byte key. Is invoked just after libssh2_hmac_ctx_init().
|
||||
|
||||
3.2) SHA-256
|
||||
Must always be implemented.
|
||||
|
||||
SHA256_DIGEST_LENGTH
|
||||
#define to 32, the SHA-256 digest length.
|
||||
|
||||
libssh2_sha256_ctx
|
||||
Type of an SHA-256 computation context. Generally a struct.
|
||||
|
||||
int libssh2_sha256_init(libssh2_sha256_ctx *x);
|
||||
Initializes the SHA-256 computation context at x.
|
||||
Returns 1 for success and 0 for failure
|
||||
|
||||
void libssh2_sha256_update(libssh2_sha256_ctx ctx,
|
||||
const unsigned char *data,
|
||||
size_t len);
|
||||
Continue computation of SHA-256 on len bytes at data using context ctx.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_sha256_final(libssh2_sha256_ctx ctx,
|
||||
unsigned char output[SHA256_DIGEST_LENGTH]);
|
||||
Gets the computed SHA-256 signature from context ctx into the output buffer.
|
||||
Release the context.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
int libssh2_sha256(const unsigned char *message,
|
||||
unsigned long len,
|
||||
unsigned char output[SHA256_DIGEST_LENGTH]);
|
||||
Computes the SHA-256 signature over the given message of length len and
|
||||
store the result into the output buffer.
|
||||
Return 1 if error, else 0.
|
||||
Note: Seems unused in current code, but defined in each crypto library backend.
|
||||
|
||||
LIBSSH2_HMAC_SHA256
|
||||
#define as 1 if the crypto library supports HMAC-SHA-256, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
void libssh2_hmac_sha256_init(libssh2_hmac_ctx *ctx,
|
||||
const void *key,
|
||||
int keylen);
|
||||
Setup the HMAC computation context ctx for an HMAC-256 computation using the
|
||||
keylen-byte key. Is invoked just after libssh2_hmac_ctx_init().
|
||||
|
||||
3.3) SHA-384
|
||||
Mandatory if ECDSA is implemented. Can be omitted otherwise.
|
||||
|
||||
SHA384_DIGEST_LENGTH
|
||||
#define to 48, the SHA-384 digest length.
|
||||
|
||||
libssh2_sha384_ctx
|
||||
Type of an SHA-384 computation context. Generally a struct.
|
||||
|
||||
int libssh2_sha384_init(libssh2_sha384_ctx *x);
|
||||
Initializes the SHA-384 computation context at x.
|
||||
Returns 1 for success and 0 for failure
|
||||
|
||||
void libssh2_sha384_update(libssh2_sha384_ctx ctx,
|
||||
const unsigned char *data,
|
||||
size_t len);
|
||||
Continue computation of SHA-384 on len bytes at data using context ctx.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_sha384_final(libssh2_sha384_ctx ctx,
|
||||
unsigned char output[SHA384_DIGEST_LENGTH]);
|
||||
Gets the computed SHA-384 signature from context ctx into the output buffer.
|
||||
Release the context.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
int libssh2_sha384(const unsigned char *message,
|
||||
unsigned long len,
|
||||
unsigned char output[SHA384_DIGEST_LENGTH]);
|
||||
Computes the SHA-384 signature over the given message of length len and
|
||||
store the result into the output buffer.
|
||||
Return 1 if error, else 0.
|
||||
|
||||
3.4) SHA-512
|
||||
Must always be implemented.
|
||||
|
||||
SHA512_DIGEST_LENGTH
|
||||
#define to 64, the SHA-512 digest length.
|
||||
|
||||
libssh2_sha512_ctx
|
||||
Type of an SHA-512 computation context. Generally a struct.
|
||||
|
||||
int libssh2_sha512_init(libssh2_sha512_ctx *x);
|
||||
Initializes the SHA-512 computation context at x.
|
||||
Returns 1 for success and 0 for failure
|
||||
|
||||
void libssh2_sha512_update(libssh2_sha512_ctx ctx,
|
||||
const unsigned char *data,
|
||||
size_t len);
|
||||
Continue computation of SHA-512 on len bytes at data using context ctx.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_sha512_final(libssh2_sha512_ctx ctx,
|
||||
unsigned char output[SHA512_DIGEST_LENGTH]);
|
||||
Gets the computed SHA-512 signature from context ctx into the output buffer.
|
||||
Release the context.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
int libssh2_sha512(const unsigned char *message,
|
||||
unsigned long len,
|
||||
unsigned char output[SHA512_DIGEST_LENGTH]);
|
||||
Computes the SHA-512 signature over the given message of length len and
|
||||
store the result into the output buffer.
|
||||
Return 1 if error, else 0.
|
||||
Note: Seems unused in current code, but defined in each crypto library backend.
|
||||
|
||||
LIBSSH2_HMAC_SHA512
|
||||
#define as 1 if the crypto library supports HMAC-SHA-512, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
void libssh2_hmac_sha512_init(libssh2_hmac_ctx *ctx,
|
||||
const void *key,
|
||||
int keylen);
|
||||
Setup the HMAC computation context ctx for an HMAC-512 computation using the
|
||||
keylen-byte key. Is invoked just after libssh2_hmac_ctx_init().
|
||||
|
||||
3.5) MD5
|
||||
LIBSSH2_MD5
|
||||
#define to 1 if the crypto library supports MD5, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
MD5_DIGEST_LENGTH
|
||||
#define to 16, the MD5 digest length.
|
||||
|
||||
libssh2_md5_ctx
|
||||
Type of an MD5 computation context. Generally a struct.
|
||||
|
||||
int libssh2_md5_init(libssh2_md5_ctx *x);
|
||||
Initializes the MD5 computation context at x.
|
||||
Returns 1 for success and 0 for failure
|
||||
|
||||
void libssh2_md5_update(libssh2_md5_ctx ctx,
|
||||
const unsigned char *data,
|
||||
size_t len);
|
||||
Continues computation of MD5 on len bytes at data using context ctx.
|
||||
Returns 1 for success and 0 for failure.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_md5_final(libssh2_md5_ctx ctx,
|
||||
unsigned char output[MD5_DIGEST_LENGTH]);
|
||||
Gets the computed MD5 signature from context ctx into the output buffer.
|
||||
Release the context.
|
||||
Note: if the ctx parameter is modified by the underlying code,
|
||||
this procedure must be implemented as a macro to map ctx --> &ctx.
|
||||
|
||||
void libssh2_hmac_md5_init(libssh2_hmac_ctx *ctx,
|
||||
const void *key,
|
||||
int keylen);
|
||||
Setup the HMAC computation context ctx for an HMAC-MD5 computation using the
|
||||
keylen-byte key. Is invoked just after libssh2_hmac_ctx_init().
|
||||
|
||||
3.6) RIPEMD-160
|
||||
LIBSSH2_HMAC_RIPEMD
|
||||
#define as 1 if the crypto library supports HMAC-RIPEMD-160, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
void libssh2_hmac_ripemd160_init(libssh2_hmac_ctx *ctx,
|
||||
const void *key,
|
||||
int keylen);
|
||||
Setup the HMAC computation context ctx for an HMAC-RIPEMD-160 computation using
|
||||
the keylen-byte key. Is invoked just after libssh2_hmac_ctx_init().
|
||||
Returns 1 for success and 0 for failure.
|
||||
|
||||
|
||||
4) Bidirectional key ciphers.
|
||||
|
||||
_libssh2_cipher_ctx
|
||||
Type of a cipher computation context.
|
||||
|
||||
_libssh2_cipher_type(name);
|
||||
Macro defining name as storage identifying a cipher algorithm for
|
||||
the crypto library interface. No trailing semicolon.
|
||||
|
||||
int _libssh2_cipher_init(_libssh2_cipher_ctx *h,
|
||||
_libssh2_cipher_type(algo),
|
||||
unsigned char *iv,
|
||||
unsigned char *secret,
|
||||
int encrypt);
|
||||
Creates a cipher context for the given algorithm with the initialization vector
|
||||
iv and the secret key secret. Prepare for encryption or decryption depending on
|
||||
encrypt.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_cipher_crypt(_libssh2_cipher_ctx *ctx,
|
||||
_libssh2_cipher_type(algo),
|
||||
int encrypt,
|
||||
unsigned char *block,
|
||||
size_t blocksize);
|
||||
Encrypt or decrypt in-place data at (block, blocksize) using the given
|
||||
context and/or algorithm.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
void _libssh2_cipher_dtor(_libssh2_cipher_ctx *ctx);
|
||||
Release cipher context at ctx.
|
||||
|
||||
4.1) AES
|
||||
4.1.1) AES in CBC block mode.
|
||||
LIBSSH2_AES
|
||||
#define as 1 if the crypto library supports AES in CBC mode, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_aes128
|
||||
AES-128-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
_libssh2_cipher_aes192
|
||||
AES-192-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
_libssh2_cipher_aes256
|
||||
AES-256-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
4.1.2) AES in CTR block mode.
|
||||
LIBSSH2_AES_CTR
|
||||
#define as 1 if the crypto library supports AES in CTR mode, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_aes128ctr
|
||||
AES-128-CTR algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
_libssh2_cipher_aes192ctr
|
||||
AES-192-CTR algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
_libssh2_cipher_aes256ctr
|
||||
AES-256-CTR algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
4.2) Blowfish in CBC block mode.
|
||||
LIBSSH2_BLOWFISH
|
||||
#define as 1 if the crypto library supports blowfish in CBC mode, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_blowfish
|
||||
Blowfish-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
4.3) RC4.
|
||||
LIBSSH2_RC4
|
||||
#define as 1 if the crypto library supports RC4 (arcfour), else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_arcfour
|
||||
RC4 algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
4.4) CAST5 in CBC block mode.
|
||||
LIBSSH2_CAST
|
||||
#define 1 if the crypto library supports cast, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_cast5
|
||||
CAST5-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
4.5) Tripple DES in CBC block mode.
|
||||
LIBSSH2_3DES
|
||||
#define as 1 if the crypto library supports TripleDES in CBC mode, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
_libssh2_cipher_3des
|
||||
TripleDES-CBC algorithm identifier initializer.
|
||||
#define with constant value of type _libssh2_cipher_type().
|
||||
|
||||
|
||||
5) Diffie-Hellman support.
|
||||
|
||||
5.1) Diffie-Hellman context.
|
||||
_libssh2_dh_ctx
|
||||
Type of a Diffie-Hellman computation context.
|
||||
Must always be defined.
|
||||
|
||||
5.2) Diffie-Hellman computation procedures.
|
||||
void libssh2_dh_init(_libssh2_dh_ctx *dhctx);
|
||||
Initializes the Diffie-Hellman context at `dhctx'. No effective context
|
||||
creation needed here.
|
||||
|
||||
int libssh2_dh_key_pair(_libssh2_dh_ctx *dhctx, _libssh2_bn *public,
|
||||
_libssh2_bn *g, _libssh2_bn *p, int group_order,
|
||||
_libssh2_bn_ctx *bnctx);
|
||||
Generates a Diffie-Hellman key pair using base `g', prime `p' and the given
|
||||
`group_order'. Can use the given big number context `bnctx' if needed.
|
||||
The private key is stored as opaque in the Diffie-Hellman context `*dhctx' and
|
||||
the public key is returned in `public'.
|
||||
0 is returned upon success, else -1.
|
||||
|
||||
int libssh2_dh_secret(_libssh2_dh_ctx *dhctx, _libssh2_bn *secret,
|
||||
_libssh2_bn *f, _libssh2_bn *p, _libssh2_bn_ctx * bnctx)
|
||||
Computes the Diffie-Hellman secret from the previously created context `*dhctx',
|
||||
the public key `f' from the other party and the same prime `p' used at
|
||||
context creation. The result is stored in `secret'.
|
||||
0 is returned upon success, else -1.
|
||||
|
||||
void libssh2_dh_dtor(_libssh2_dh_ctx *dhctx)
|
||||
Destroys Diffie-Hellman context at `dhctx' and resets its storage.
|
||||
|
||||
|
||||
6) Big numbers.
|
||||
Positive multi-byte integers support is sufficient.
|
||||
|
||||
6.1) Computation contexts.
|
||||
This has a real meaning if the big numbers computations need some context
|
||||
storage. If not, use a dummy type and functions (macros).
|
||||
|
||||
_libssh2_bn_ctx
|
||||
Type of multiple precision computation context. May not be empty. if not used,
|
||||
#define as char, for example.
|
||||
|
||||
_libssh2_bn_ctx _libssh2_bn_ctx_new(void);
|
||||
Returns a new multiple precision computation context.
|
||||
|
||||
void _libssh2_bn_ctx_free(_libssh2_bn_ctx ctx);
|
||||
Releases a multiple precision computation context.
|
||||
|
||||
6.2) Computation support.
|
||||
_libssh2_bn
|
||||
Type of multiple precision numbers (aka bignumbers or huge integers) for the
|
||||
crypto library.
|
||||
|
||||
_libssh2_bn * _libssh2_bn_init(void);
|
||||
Creates a multiple precision number (preset to zero).
|
||||
|
||||
_libssh2_bn * _libssh2_bn_init_from_bin(void);
|
||||
Create a multiple precision number intended to be set by the
|
||||
_libssh2_bn_from_bin() function (see below). Unlike _libssh2_bn_init(), this
|
||||
code may be a dummy initializer if the _libssh2_bn_from_bin() actually
|
||||
allocates the number. Returns a value of type _libssh2_bn *.
|
||||
|
||||
void _libssh2_bn_free(_libssh2_bn *bn);
|
||||
Destroys the multiple precision number at bn.
|
||||
|
||||
unsigned long _libssh2_bn_bytes(_libssh2_bn *bn);
|
||||
Get the number of bytes needed to store the bits of the multiple precision
|
||||
number at bn.
|
||||
|
||||
unsigned long _libssh2_bn_bits(_libssh2_bn *bn);
|
||||
Returns the number of bits of multiple precision number at bn.
|
||||
|
||||
int _libssh2_bn_set_word(_libssh2_bn *bn, unsigned long val);
|
||||
Sets the value of bn to val.
|
||||
Returns 1 on success, 0 otherwise.
|
||||
|
||||
_libssh2_bn * _libssh2_bn_from_bin(_libssh2_bn *bn, int len,
|
||||
const unsigned char *val);
|
||||
Converts the positive integer in big-endian form of length len at val
|
||||
into a _libssh2_bn and place it in bn. If bn is NULL, a new _libssh2_bn is
|
||||
created.
|
||||
Returns a pointer to target _libssh2_bn or NULL if error.
|
||||
|
||||
int _libssh2_bn_to_bin(_libssh2_bn *bn, unsigned char *val);
|
||||
Converts the absolute value of bn into big-endian form and store it at
|
||||
val. val must point to _libssh2_bn_bytes(bn) bytes of memory.
|
||||
Returns the length of the big-endian number.
|
||||
|
||||
|
||||
7) Private key algorithms.
|
||||
Format of an RSA public key:
|
||||
a) "ssh-rsa".
|
||||
b) RSA exponent, MSB first, with high order bit = 0.
|
||||
c) RSA modulus, MSB first, with high order bit = 0.
|
||||
Each item is preceded by its 32-bit byte length, MSB first.
|
||||
|
||||
Format of a DSA public key:
|
||||
a) "ssh-dss".
|
||||
b) p, MSB first, with high order bit = 0.
|
||||
c) q, MSB first, with high order bit = 0.
|
||||
d) g, MSB first, with high order bit = 0.
|
||||
e) pub_key, MSB first, with high order bit = 0.
|
||||
Each item is preceded by its 32-bit byte length, MSB first.
|
||||
|
||||
Format of an ECDSA public key:
|
||||
a) "ecdsa-sha2-nistp256" or "ecdsa-sha2-nistp384" or "ecdsa-sha2-nistp521".
|
||||
b) domain: "nistp256", "nistp384" or "nistp521" matching a).
|
||||
c) raw public key ("octal").
|
||||
Each item is preceded by its 32-bit byte length, MSB first.
|
||||
|
||||
Format of an ED25519 public key:
|
||||
a) "ssh-ed25519".
|
||||
b) raw key (32 bytes).
|
||||
Each item is preceded by its 32-bit byte length, MSB first.
|
||||
|
||||
int _libssh2_pub_priv_keyfile(LIBSSH2_SESSION *session,
|
||||
unsigned char **method,
|
||||
size_t *method_len,
|
||||
unsigned char **pubkeydata,
|
||||
size_t *pubkeydata_len,
|
||||
const char *privatekey,
|
||||
const char *passphrase);
|
||||
Reads a private key from file privatekey and extract the public key -->
|
||||
(pubkeydata, pubkeydata_len). Store the associated method (ssh-rsa or ssh-dss)
|
||||
into (method, method_len).
|
||||
Both buffers have to be allocated using LIBSSH2_ALLOC().
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_pub_priv_keyfilememory(LIBSSH2_SESSION *session,
|
||||
unsigned char **method,
|
||||
size_t *method_len,
|
||||
unsigned char **pubkeydata,
|
||||
size_t *pubkeydata_len,
|
||||
const char *privatekeydata,
|
||||
size_t privatekeydata_len,
|
||||
const char *passphrase);
|
||||
Gets a private key from bytes at (privatekeydata, privatekeydata_len) and
|
||||
extract the public key --> (pubkeydata, pubkeydata_len). Store the associated
|
||||
method (ssh-rsa or ssh-dss) into (method, method_len).
|
||||
Both buffers have to be allocated using LIBSSH2_ALLOC().
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
|
||||
7.1) RSA
|
||||
LIBSSH2_RSA
|
||||
#define as 1 if the crypto library supports RSA, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
libssh2_rsa_ctx
|
||||
Type of an RSA computation context. Generally a struct.
|
||||
|
||||
int _libssh2_rsa_new(libssh2_rsa_ctx **rsa,
|
||||
const unsigned char *edata,
|
||||
unsigned long elen,
|
||||
const unsigned char *ndata,
|
||||
unsigned long nlen,
|
||||
const unsigned char *ddata,
|
||||
unsigned long dlen,
|
||||
const unsigned char *pdata,
|
||||
unsigned long plen,
|
||||
const unsigned char *qdata,
|
||||
unsigned long qlen,
|
||||
const unsigned char *e1data,
|
||||
unsigned long e1len,
|
||||
const unsigned char *e2data,
|
||||
unsigned long e2len,
|
||||
const unsigned char *coeffdata, unsigned long coefflen);
|
||||
Creates a new context for RSA computations from key source values:
|
||||
pdata, plen Prime number p. Only used if private key known (ddata).
|
||||
qdata, qlen Prime number q. Only used if private key known (ddata).
|
||||
ndata, nlen Modulus n.
|
||||
edata, elen Exponent e.
|
||||
ddata, dlen e^-1 % phi(n) = private key. May be NULL if unknown.
|
||||
e1data, e1len dp = d % (p-1). Only used if private key known (dtata).
|
||||
e2data, e2len dq = d % (q-1). Only used if private key known (dtata).
|
||||
coeffdata, coefflen q^-1 % p. Only used if private key known.
|
||||
Returns 0 if OK.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
Note: the current generic code only calls this function with e and n (public
|
||||
key parameters): unless used internally by the backend, it is not needed to
|
||||
support the private key and the other parameters here.
|
||||
|
||||
int _libssh2_rsa_new_private(libssh2_rsa_ctx **rsa,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *filename,
|
||||
unsigned const char *passphrase);
|
||||
Reads an RSA private key from file filename into a new RSA context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_rsa_new_private_frommemory(libssh2_rsa_ctx **rsa,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *data,
|
||||
size_t data_len,
|
||||
unsigned const char *passphrase);
|
||||
Gets an RSA private key from data into a new RSA context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_rsa_sha1_verify(libssh2_rsa_ctx *rsa,
|
||||
const unsigned char *sig,
|
||||
unsigned long sig_len,
|
||||
const unsigned char *m, unsigned long m_len);
|
||||
Verify (sig, sig_len) signature of (m, m_len) using an SHA-1 hash and the
|
||||
RSA context.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_rsa_sha1_signv(LIBSSH2_SESSION *session,
|
||||
unsigned char **sig, size_t *siglen,
|
||||
int count, const struct iovec vector[],
|
||||
libssh2_rsa_ctx *ctx);
|
||||
RSA signs the SHA-1 hash computed over the count data chunks in vector.
|
||||
Signature is stored at (sig, siglen).
|
||||
Signature buffer must be allocated from the given session.
|
||||
Returns 0 if OK, else -1.
|
||||
Note: this procedure is optional: if provided, it MUST be defined as a macro.
|
||||
|
||||
int _libssh2_rsa_sha1_sign(LIBSSH2_SESSION *session,
|
||||
libssh2_rsa_ctx *rsactx,
|
||||
const unsigned char *hash,
|
||||
size_t hash_len,
|
||||
unsigned char **signature,
|
||||
size_t *signature_len);
|
||||
RSA signs the (hash, hashlen) SHA-1 hash bytes and stores the allocated
|
||||
signature at (signature, signature_len).
|
||||
Signature buffer must be allocated from the given session.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
Note: this procedure is not used if macro _libssh2_rsa_sha1_signv() is defined.
|
||||
|
||||
void _libssh2_rsa_free(libssh2_rsa_ctx *rsactx);
|
||||
Releases the RSA computation context at rsactx.
|
||||
|
||||
|
||||
7.2) DSA
|
||||
LIBSSH2_DSA
|
||||
#define as 1 if the crypto library supports DSA, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
|
||||
libssh2_dsa_ctx
|
||||
Type of a DSA computation context. Generally a struct.
|
||||
|
||||
int _libssh2_dsa_new(libssh2_dsa_ctx **dsa,
|
||||
const unsigned char *pdata,
|
||||
unsigned long plen,
|
||||
const unsigned char *qdata,
|
||||
unsigned long qlen,
|
||||
const unsigned char *gdata,
|
||||
unsigned long glen,
|
||||
const unsigned char *ydata,
|
||||
unsigned long ylen,
|
||||
const unsigned char *x, unsigned long x_len);
|
||||
Creates a new context for DSA computations from source key values:
|
||||
pdata, plen Prime number p. Only used if private key known (ddata).
|
||||
qdata, qlen Prime number q. Only used if private key known (ddata).
|
||||
gdata, glen G number.
|
||||
ydata, ylen Public key.
|
||||
xdata, xlen Private key. Only taken if xlen non-zero.
|
||||
Returns 0 if OK.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_dsa_new_private(libssh2_dsa_ctx **dsa,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *filename,
|
||||
unsigned const char *passphrase);
|
||||
Gets a DSA private key from file filename into a new DSA context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_dsa_new_private_frommemory(libssh2_dsa_ctx **dsa,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *data,
|
||||
size_t data_len,
|
||||
unsigned const char *passphrase);
|
||||
Gets a DSA private key from the data_len-bytes data into a new DSA context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_dsa_sha1_verify(libssh2_dsa_ctx *dsactx,
|
||||
const unsigned char *sig,
|
||||
const unsigned char *m, unsigned long m_len);
|
||||
Verify (sig, siglen) signature of (m, m_len) using an SHA-1 hash and the
|
||||
DSA context.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_dsa_sha1_sign(libssh2_dsa_ctx *dsactx,
|
||||
const unsigned char *hash,
|
||||
unsigned long hash_len, unsigned char *sig);
|
||||
DSA signs the (hash, hash_len) data using SHA-1 and store the signature at sig.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
void _libssh2_dsa_free(libssh2_dsa_ctx *dsactx);
|
||||
Releases the DSA computation context at dsactx.
|
||||
|
||||
|
||||
7.3) ECDSA
|
||||
LIBSSH2_ECDSA
|
||||
#define as 1 if the crypto library supports ECDSA, else 0.
|
||||
If defined as 0, _libssh2_ec_key should be defined as void and the rest of
|
||||
this section can be omitted.
|
||||
|
||||
EC_MAX_POINT_LEN
|
||||
Maximum point length. Usually defined as ((528 * 2 / 8) + 1) (= 133).
|
||||
|
||||
libssh2_ecdsa_ctx
|
||||
Type of an ECDSA computation context. Generally a struct.
|
||||
|
||||
_libssh2_ec_key
|
||||
Type of an elliptic curve key.
|
||||
|
||||
libssh2_curve_type
|
||||
An enum type defining curve types. Current supported identifiers are:
|
||||
LIBSSH2_EC_CURVE_NISTP256
|
||||
LIBSSH2_EC_CURVE_NISTP384
|
||||
LIBSSH2_EC_CURVE_NISTP521
|
||||
|
||||
int _libssh2_ecdsa_create_key(_libssh2_ec_key **out_private_key,
|
||||
unsigned char **out_public_key_octal,
|
||||
size_t *out_public_key_octal_len,
|
||||
libssh2_curve_type curve_type);
|
||||
Create a new ECDSA private key of type curve_type and return it at
|
||||
out_private_key. If out_public_key_octal is not NULL, store an allocated
|
||||
pointer to the associated public key in "octal" form in it and its length
|
||||
at out_public_key_octal_len.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_new_private(libssh2_ecdsa_ctx **ec_ctx,
|
||||
LIBSSH2_SESSION * session,
|
||||
const char *filename,
|
||||
unsigned const char *passphrase);
|
||||
Reads an ECDSA private key from PEM file filename into a new ECDSA context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_new_private_frommemory(libssh2_ecdsa_ctx ** ec_ctx,
|
||||
LIBSSH2_SESSION * session,
|
||||
const char *filedata,
|
||||
size_t filedata_len,
|
||||
unsigned const char *passphrase);
|
||||
Builds an ECDSA private key from PEM data at filedata of length filedata_len
|
||||
into a new ECDSA context stored at ec_ctx.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_curve_name_with_octal_new(libssh2_ecdsa_ctx **ecdsactx,
|
||||
const unsigned char *k,
|
||||
size_t k_len,
|
||||
libssh2_curve_type type);
|
||||
Stores at ecdsactx a new ECDSA context associated with the given curve type
|
||||
and with "octal" form public key (k, k_len).
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_new_openssh_private(libssh2_ecdsa_ctx **ec_ctx,
|
||||
LIBSSH2_SESSION * session,
|
||||
const char *filename,
|
||||
unsigned const char *passphrase);
|
||||
Reads a PEM-encoded ECDSA private key from file filename encrypted with
|
||||
passphrase and stores at ec_ctx a new ECDSA context for it.
|
||||
Return 0 if OK, else -1.
|
||||
Currently used only from openssl backend (ought to be private).
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_sign(LIBSSH2_SESSION *session, libssh2_ecdsa_ctx *ec_ctx,
|
||||
const unsigned char *hash, unsigned long hash_len,
|
||||
unsigned char **signature, size_t *signature_len);
|
||||
ECDSA signs the (hash, hashlen) hash bytes and stores the allocated
|
||||
signature at (signature, signature_len). Hash algorithm used should be
|
||||
SHA-256, SHA-384 or SHA-512 depending on type stored in ECDSA context at ec_ctx.
|
||||
Signature buffer must be allocated from the given session.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_verify(libssh2_ecdsa_ctx *ctx,
|
||||
const unsigned char *r, size_t r_len,
|
||||
const unsigned char *s, size_t s_len,
|
||||
const unsigned char *m, size_t m_len);
|
||||
Verify the ECDSA signature made of (r, r_len) and (s, s_len) of (m, m_len)
|
||||
using the hash algorithm configured in the ECDSA context ctx.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
libssh2_curve_type _libssh2_ecdsa_get_curve_type(libssh2_ecdsa_ctx *ecdsactx);
|
||||
Returns the curve type associated with given context.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ecdsa_curve_type_from_name(const char *name,
|
||||
libssh2_curve_type *out_type);
|
||||
Stores in out_type the curve type matching string name of the form
|
||||
"ecdsa-sha2-nistpxxx".
|
||||
Return 0 if OK, else -1.
|
||||
Currently used only from openssl backend (ought to be private).
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
void _libssh2_ecdsa_free(libssh2_ecdsa_ctx *ecdsactx);
|
||||
Releases the ECDSA computation context at ecdsactx.
|
||||
|
||||
|
||||
7.4) ED25519
|
||||
LIBSSH2_ED25519
|
||||
#define as 1 if the crypto library supports ED25519, else 0.
|
||||
If defined as 0, the rest of this section can be omitted.
|
||||
|
||||
|
||||
libssh2_ed25519_ctx
|
||||
Type of an ED25519 computation context. Generally a struct.
|
||||
|
||||
int _libssh2_curve25519_new(LIBSSH2_SESSION *session, libssh2_ed25519_ctx **ctx,
|
||||
uint8_t **out_public_key,
|
||||
uint8_t **out_private_key);
|
||||
Generates an ED25519 key pair, stores a pointer to them at out_private_key
|
||||
and out_public_key respectively and stores at ctx a new ED25519 context for
|
||||
this key.
|
||||
Argument ctx, out_private_key and out_public key may be NULL to disable storing
|
||||
the corresponding value.
|
||||
Length of each key is LIBSSH2_ED25519_KEY_LEN (32 bytes).
|
||||
Key buffers are allocated and should be released by caller after use.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ed25519_new_private(libssh2_ed25519_ctx **ed_ctx,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *filename,
|
||||
const uint8_t *passphrase);
|
||||
Reads an ED25519 private key from PEM file filename into a new ED25519 context.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ed25519_new_public(libssh2_ed25519_ctx **ed_ctx,
|
||||
LIBSSH2_SESSION *session,
|
||||
const unsigned char *raw_pub_key,
|
||||
const uint8_t key_len);
|
||||
Stores at ed_ctx a new ED25519 key context for raw public key (raw_pub_key,
|
||||
key_len).
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ed25519_new_private_frommemory(libssh2_ed25519_ctx **ed_ctx,
|
||||
LIBSSH2_SESSION *session,
|
||||
const char *filedata,
|
||||
size_t filedata_len,
|
||||
unsigned const char *passphrase);
|
||||
Builds an ED25519 private key from PEM data at filedata of length filedata_len
|
||||
into a new ED25519 context stored at ed_ctx.
|
||||
Must call _libssh2_init_if_needed().
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ed25519_sign(libssh2_ed25519_ctx *ctx, LIBSSH2_SESSION *session,
|
||||
uint8_t **out_sig, size_t *out_sig_len,
|
||||
const uint8_t *message, size_t message_len);
|
||||
ED25519 signs the (message, message_len) bytes and stores the allocated
|
||||
signature at (sig, sig_len).
|
||||
Signature buffer is allocated from the given session.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_ed25519_verify(libssh2_ed25519_ctx *ctx, const uint8_t *s,
|
||||
size_t s_len, const uint8_t *m, size_t m_len);
|
||||
Verify (s, s_len) signature of (m, m_len) using the given ED25519 context.
|
||||
Return 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
int _libssh2_curve25519_gen_k(_libssh2_bn **k,
|
||||
uint8_t private_key[LIBSSH2_ED25519_KEY_LEN],
|
||||
uint8_t srvr_public_key[LIBSSH2_ED25519_KEY_LEN]);
|
||||
Computes a shared ED25519 secret key from the given raw server public key and
|
||||
raw client public key and stores it as a big number in *k. Big number should
|
||||
have been initialized before calling this function.
|
||||
Returns 0 if OK, else -1.
|
||||
This procedure is already prototyped in crypto.h.
|
||||
|
||||
void _libssh2_ed25519_free(libssh2_ed25519_ctx *ed25519ctx);
|
||||
Releases the ED25519 computation context at ed25519ctx.
|
||||
|
||||
|
||||
8) Miscellaneous
|
||||
|
||||
void libssh2_prepare_iovec(struct iovec *vector, unsigned int len);
|
||||
Prepare len consecutive iovec slots before using them.
|
||||
In example, this is needed to preset unused structure slacks on platforms
|
||||
requiring it.
|
||||
If this is not needed, it should be defined as an empty macro.
|
||||
|
||||
int _libssh2_random(unsigned char *buf, int len);
|
||||
Store len random bytes at buf.
|
||||
Returns 0 if OK, else -1.
|
||||
@ -0,0 +1,13 @@
|
||||
|
||||
libssh2 source code style guide:
|
||||
|
||||
- 4 level indent
|
||||
- spaces-only (no tabs)
|
||||
- open braces on the if/for line:
|
||||
|
||||
if (banana) {
|
||||
go_nuts();
|
||||
}
|
||||
|
||||
- keep source lines shorter than 80 columns
|
||||
- See libssh2-style.el for how to achieve this within Emacs
|
||||
@ -0,0 +1,355 @@
|
||||
Installation Instructions
|
||||
*************************
|
||||
|
||||
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free
|
||||
Software Foundation, Inc.
|
||||
|
||||
This file is free documentation; the Free Software Foundation gives
|
||||
unlimited permission to copy, distribute and modify it.
|
||||
|
||||
When Building directly from Master
|
||||
==================================
|
||||
|
||||
If you want to build directly from the git repository, you must first
|
||||
generate the configure script and Makefile using autotools. There is
|
||||
a convenience script that calls all tools in the correct order. Make
|
||||
sure that autoconf, automake and libtool are installed on your system,
|
||||
then execute:
|
||||
|
||||
autoreconf -fi
|
||||
|
||||
After executing this script, you can build the project as usual:
|
||||
|
||||
./configure
|
||||
make
|
||||
|
||||
Basic Installation
|
||||
==================
|
||||
|
||||
These are generic installation instructions.
|
||||
|
||||
The `configure' shell script attempts to guess correct values for
|
||||
various system-dependent variables used during compilation. It uses
|
||||
those values to create a `Makefile' in each directory of the package.
|
||||
It may also create one or more `.h' files containing system-dependent
|
||||
definitions. Finally, it creates a shell script `config.status' that
|
||||
you can run in the future to recreate the current configuration, and a
|
||||
file `config.log' containing compiler output (useful mainly for
|
||||
debugging `configure').
|
||||
|
||||
It can also use an optional file (typically called `config.cache'
|
||||
and enabled with `--cache-file=config.cache' or simply `-C') that saves
|
||||
the results of its tests to speed up reconfiguring. (Caching is
|
||||
disabled by default to prevent problems with accidental use of stale
|
||||
cache files.)
|
||||
|
||||
If you need to do unusual things to compile the package, please try
|
||||
to figure out how `configure' could check whether to do them, and mail
|
||||
diffs or instructions to the address given in the `README' so they can
|
||||
be considered for the next release. If you are using the cache, and at
|
||||
some point `config.cache' contains results you don't want to keep, you
|
||||
may remove or edit it.
|
||||
|
||||
The file `configure.ac' (or `configure.in') is used to create
|
||||
`configure' by a program called `autoconf'. You only need
|
||||
`configure.ac' if you want to change it or regenerate `configure' using
|
||||
a newer version of `autoconf'.
|
||||
|
||||
The simplest way to compile this package is:
|
||||
|
||||
1. `cd' to the directory containing the package's source code and type
|
||||
`./configure' to configure the package for your system. If you're
|
||||
using `csh' on an old version of System V, you might need to type
|
||||
`sh ./configure' instead to prevent `csh' from trying to execute
|
||||
`configure' itself.
|
||||
|
||||
Running `configure' takes awhile. While running, it prints some
|
||||
messages telling which features it is checking for.
|
||||
|
||||
2. Type `make' to compile the package.
|
||||
|
||||
3. Optionally, type `make check' to run any self-tests that come with
|
||||
the package.
|
||||
|
||||
4. Type `make install' to install the programs and any data files and
|
||||
documentation.
|
||||
|
||||
5. You can remove the program binaries and object files from the
|
||||
source code directory by typing `make clean'. To also remove the
|
||||
files that `configure' created (so you can compile the package for
|
||||
a different kind of computer), type `make distclean'. There is
|
||||
also a `make maintainer-clean' target, but that is intended mainly
|
||||
for the package's developers. If you use it, you may have to get
|
||||
all sorts of other programs in order to regenerate files that came
|
||||
with the distribution.
|
||||
|
||||
Compilers and Options
|
||||
=====================
|
||||
|
||||
Some systems require unusual options for compilation or linking that the
|
||||
`configure' script does not know about. Run `./configure --help' for
|
||||
details on some of the pertinent environment variables.
|
||||
|
||||
You can give `configure' initial values for configuration parameters
|
||||
by setting variables in the command line or in the environment. Here
|
||||
is an example:
|
||||
|
||||
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
|
||||
|
||||
*Note Defining Variables::, for more details.
|
||||
|
||||
Compiling For Multiple Architectures
|
||||
====================================
|
||||
|
||||
You can compile the package for more than one kind of computer at the
|
||||
same time, by placing the object files for each architecture in their
|
||||
own directory. To do this, you must use a version of `make' that
|
||||
supports the `VPATH' variable, such as GNU `make'. `cd' to the
|
||||
directory where you want the object files and executables to go and run
|
||||
the `configure' script. `configure' automatically checks for the
|
||||
source code in the directory that `configure' is in and in `..'.
|
||||
|
||||
If you have to use a `make' that does not support the `VPATH'
|
||||
variable, you have to compile the package for one architecture at a
|
||||
time in the source code directory. After you have installed the
|
||||
package for one architecture, use `make distclean' before reconfiguring
|
||||
for another architecture.
|
||||
|
||||
Installation Names
|
||||
==================
|
||||
|
||||
By default, `make install' installs the package's commands under
|
||||
`/usr/local/bin', include files under `/usr/local/include', etc. You
|
||||
can specify an installation prefix other than `/usr/local' by giving
|
||||
`configure' the option `--prefix=PREFIX'.
|
||||
|
||||
You can specify separate installation prefixes for
|
||||
architecture-specific files and architecture-independent files. If you
|
||||
pass the option `--exec-prefix=PREFIX' to `configure', the package uses
|
||||
PREFIX as the prefix for installing programs and libraries.
|
||||
Documentation and other data files still use the regular prefix.
|
||||
|
||||
In addition, if you use an unusual directory layout you can give
|
||||
options like `--bindir=DIR' to specify different values for particular
|
||||
kinds of files. Run `configure --help' for a list of the directories
|
||||
you can set and what kinds of files go in them.
|
||||
|
||||
If the package supports it, you can cause programs to be installed
|
||||
with an extra prefix or suffix on their names by giving `configure' the
|
||||
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
|
||||
|
||||
Optional Features
|
||||
=================
|
||||
|
||||
Some packages pay attention to `--enable-FEATURE' options to
|
||||
`configure', where FEATURE indicates an optional part of the package.
|
||||
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
|
||||
is something like `gnu-as' or `x' (for the X Window System). The
|
||||
`README' should mention any `--enable-' and `--with-' options that the
|
||||
package recognizes.
|
||||
|
||||
For packages that use the X Window System, `configure' can usually
|
||||
find the X include and library files automatically, but if it doesn't,
|
||||
you can use the `configure' options `--x-includes=DIR' and
|
||||
`--x-libraries=DIR' to specify their locations.
|
||||
|
||||
Specifying the System Type
|
||||
==========================
|
||||
|
||||
There may be some features `configure' cannot figure out automatically,
|
||||
but needs to determine by the type of machine the package will run on.
|
||||
Usually, assuming the package is built to be run on the _same_
|
||||
architectures, `configure' can figure that out, but if it prints a
|
||||
message saying it cannot guess the machine type, give it the
|
||||
`--build=TYPE' option. TYPE can either be a short name for the system
|
||||
type, such as `sun4', or a canonical name which has the form:
|
||||
|
||||
CPU-COMPANY-SYSTEM
|
||||
|
||||
where SYSTEM can have one of these forms:
|
||||
|
||||
OS KERNEL-OS
|
||||
|
||||
See the file `config.sub' for the possible values of each field. If
|
||||
`config.sub' isn't included in this package, then this package doesn't
|
||||
need to know the machine type.
|
||||
|
||||
If you are _building_ compiler tools for cross-compiling, you should
|
||||
use the option `--target=TYPE' to select the type of system they will
|
||||
produce code for.
|
||||
|
||||
If you want to _use_ a cross compiler, that generates code for a
|
||||
platform different from the build platform, you should specify the
|
||||
"host" platform (i.e., that on which the generated programs will
|
||||
eventually be run) with `--host=TYPE'.
|
||||
|
||||
Sharing Defaults
|
||||
================
|
||||
|
||||
If you want to set default values for `configure' scripts to share, you
|
||||
can create a site shell script called `config.site' that gives default
|
||||
values for variables like `CC', `cache_file', and `prefix'.
|
||||
`configure' looks for `PREFIX/share/config.site' if it exists, then
|
||||
`PREFIX/etc/config.site' if it exists. Or, you can set the
|
||||
`CONFIG_SITE' environment variable to the location of the site script.
|
||||
A warning: not all `configure' scripts look for a site script.
|
||||
|
||||
Defining Variables
|
||||
==================
|
||||
|
||||
Variables not defined in a site shell script can be set in the
|
||||
environment passed to `configure'. However, some packages may run
|
||||
configure again during the build, and the customized values of these
|
||||
variables may be lost. In order to avoid this problem, you should set
|
||||
them in the `configure' command line, using `VAR=value'. For example:
|
||||
|
||||
./configure CC=/usr/local2/bin/gcc
|
||||
|
||||
causes the specified `gcc' to be used as the C compiler (unless it is
|
||||
overridden in the site shell script). Here is a another example:
|
||||
|
||||
/bin/bash ./configure CONFIG_SHELL=/bin/bash
|
||||
|
||||
Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
|
||||
configuration-related scripts to be executed by `/bin/bash'.
|
||||
|
||||
`configure' Invocation
|
||||
======================
|
||||
|
||||
`configure' recognizes the following options to control how it operates.
|
||||
|
||||
`--help'
|
||||
`-h'
|
||||
Print a summary of the options to `configure', and exit.
|
||||
|
||||
`--version'
|
||||
`-V'
|
||||
Print the version of Autoconf used to generate the `configure'
|
||||
script, and exit.
|
||||
|
||||
`--cache-file=FILE'
|
||||
Enable the cache: use and save the results of the tests in FILE,
|
||||
traditionally `config.cache'. FILE defaults to `/dev/null' to
|
||||
disable caching.
|
||||
|
||||
`--config-cache'
|
||||
`-C'
|
||||
Alias for `--cache-file=config.cache'.
|
||||
|
||||
`--quiet'
|
||||
`--silent'
|
||||
`-q'
|
||||
Do not print messages saying which checks are being made. To
|
||||
suppress all normal output, redirect it to `/dev/null' (any error
|
||||
messages will still be shown).
|
||||
|
||||
`--srcdir=DIR'
|
||||
Look for the package's source code in directory DIR. Usually
|
||||
`configure' can determine that directory automatically.
|
||||
|
||||
`configure' also accepts some other, not widely useful, options. Run
|
||||
`configure --help' for more details.
|
||||
|
||||
More configure options
|
||||
======================
|
||||
|
||||
Some ./configure options deserve additional comments:
|
||||
|
||||
* --enable-crypt-none
|
||||
|
||||
The SSH2 Transport allows for unencrypted data
|
||||
transmission using the "none" cipher. Because this is
|
||||
such a huge security hole, it is typically disabled on
|
||||
SSH2 implementations and is disabled in libssh2 by
|
||||
default as well.
|
||||
|
||||
Enabling this option will allow for "none" as a
|
||||
negotiable method, however it still requires that the
|
||||
method be advertized by the remote end and that no
|
||||
more-preferable methods are available.
|
||||
|
||||
* --enable-mac-none
|
||||
|
||||
The SSH2 Transport also allows implementations to
|
||||
forego a message authentication code. While this is
|
||||
less of a security risk than using a "none" cipher, it
|
||||
is still not recommended as disabling MAC hashes
|
||||
removes a layer of security.
|
||||
|
||||
Enabling this option will allow for "none" as a
|
||||
negotiable method, however it still requires that the
|
||||
method be advertized by the remote end and that no
|
||||
more-preferable methods are available.
|
||||
|
||||
* --disable-gex-new
|
||||
|
||||
The diffie-hellman-group-exchange-sha1 (dh-gex) key
|
||||
exchange method originally defined an exchange
|
||||
negotiation using packet type 30 to request a
|
||||
generation pair based on a single target value. Later
|
||||
refinement of dh-gex provided for range and target
|
||||
values. By default libssh2 will use the newer range
|
||||
method.
|
||||
|
||||
If you experience trouble connecting to an old SSH
|
||||
server using dh-gex, try this option to fallback on
|
||||
the older more reliable method.
|
||||
|
||||
* --with-libgcrypt
|
||||
* --without-libgcrypt
|
||||
* --with-libgcrypt-prefix=DIR
|
||||
|
||||
libssh2 can use the Libgcrypt library
|
||||
(https://www.gnupg.org/) for cryptographic operations.
|
||||
One of the cryptographic libraries is required.
|
||||
|
||||
Configure will attempt to locate Libgcrypt
|
||||
automatically.
|
||||
|
||||
If your installation of Libgcrypt is in another
|
||||
location, specify it using --with-libgcrypt-prefix.
|
||||
|
||||
* --with-openssl
|
||||
* --without-openssl
|
||||
* --with-libssl-prefix=[DIR]
|
||||
|
||||
libssh2 can use the OpenSSL library
|
||||
(https://www.openssl.org) for cryptographic operations.
|
||||
One of the cryptographic libraries is required.
|
||||
|
||||
Configure will attempt to locate OpenSSL in the
|
||||
default location.
|
||||
|
||||
If your installation of OpenSSL is in another
|
||||
location, specify it using --with-libssl-prefix.
|
||||
|
||||
* --with-mbedtls
|
||||
* --without-mbedtls
|
||||
* --with-libmbedtls-prefix=[DIR]
|
||||
|
||||
libssh2 can use the mbedTLS library
|
||||
(https://tls.mbed.org) for cryptographic operations.
|
||||
One of the cryptographic libraries is required.
|
||||
|
||||
Configure will attempt to locate mbedTLS in the
|
||||
default location.
|
||||
|
||||
If your installation of mbedTLS is in another
|
||||
location, specify it using --with-libmbedtls-prefix.
|
||||
|
||||
* --with-libz
|
||||
* --without-libz
|
||||
* --with-libz-prefix=[DIR]
|
||||
|
||||
If present, libssh2 will attempt to use the zlib
|
||||
(http://www.zlib.org) for payload compression, however
|
||||
zlib is not required.
|
||||
|
||||
If your installation of Libz is in another location,
|
||||
specify it using --with-libz-prefix.
|
||||
|
||||
* --enable-debug
|
||||
|
||||
Will make the build use more pedantic and strict compiler
|
||||
options as well as enable the libssh2_trace() function (for
|
||||
showing debug traces).
|
||||
@ -0,0 +1,174 @@
|
||||
Things TODO
|
||||
===========
|
||||
|
||||
* Fix the numerous malloc+copy operations for sending data, see "Buffering
|
||||
Improvements" below for details
|
||||
|
||||
* make sure the windowing code adapts better to slow situations so that it
|
||||
doesn't then use as much memory as today. Possibly by an app-controllable
|
||||
"Window mode"?
|
||||
|
||||
* Decrease the number of mallocs. Everywhere. Will get easier once the
|
||||
buffering improvements have been done.
|
||||
|
||||
* Use SO_NOSIGPIPE for Mac OS/BSD systems where MSG_NOSIGNAL doesn't
|
||||
exist/work
|
||||
|
||||
* Extend the test suite to actually test lots of aspects of libssh2
|
||||
|
||||
* Fix all compiler warnings (some can't be done without API changes)
|
||||
|
||||
* Expose error messages sent by the server
|
||||
|
||||
* select() is troublesome with libssh2 when using multiple channels over
|
||||
the same session. See "New Transport API" below for more details.
|
||||
|
||||
At next SONAME bump
|
||||
===================
|
||||
|
||||
* stop using #defined macros as part of the official API. The macros should
|
||||
either be turned into real functions or discarded from the API.
|
||||
|
||||
* fix the parts of the API where object pointers and function pointers are
|
||||
mixed like libssh2_session_callback_set()
|
||||
|
||||
* remove the following functions from the API/ABI
|
||||
|
||||
libssh2_base64_decode()
|
||||
libssh2_session_flag()
|
||||
libssh2_channel_handle_extended_data()
|
||||
libssh2_channel_receive_window_adjust()
|
||||
libssh2_poll()
|
||||
libssh2_poll_channel_read()
|
||||
libssh2_session_startup() (libssh2_session_handshake() is the replacement)
|
||||
libssh2_banner_set() (libssh2_session_banner_set() is the repacement)
|
||||
|
||||
* Rename a few function:
|
||||
|
||||
libssh2_hostkey_hash => libssh2_session_hostkey_hash
|
||||
libssh2_banner_set => libssh2_session_banner_set
|
||||
|
||||
* change 'int' to 'libssh2_socket_t' in the public API for sockets.
|
||||
|
||||
* Use 'size_t' for string lengths in all functions.
|
||||
|
||||
* Add a comment field to struct libssh2_knownhost.
|
||||
|
||||
* remove the existing libssh2_knownhost_add() function and rename
|
||||
libssh2_knownhost_addc to become the new libssh2_knownhost_add instead
|
||||
|
||||
* remove the existing libssh2_scp_send_ex() function and rename
|
||||
libssh2_scp_send64 to become the new libssh2_scp_send instead.
|
||||
|
||||
* remove the existing libssh2_knownhost_check() functin and rename
|
||||
libssh2_knownhost_checkp() to become the new libssh2_knownhost_check instead
|
||||
|
||||
Buffering Improvements
|
||||
======================
|
||||
|
||||
transport_write
|
||||
|
||||
- If this function gets called with a total packet size that is larger than
|
||||
32K, it should create more than one SSH packet so that it keeps the largest
|
||||
one below 32K
|
||||
|
||||
sftp_write
|
||||
|
||||
- should not copy/allocate anything for the data, only create a header chunk
|
||||
and pass on the payload data to channel_write "pointed to"
|
||||
|
||||
New Transport API
|
||||
=================
|
||||
|
||||
THE PROBLEM
|
||||
|
||||
The problem in a nutshell is that when an application opens up multiple
|
||||
channels over a single session, those are all using the same socket. If the
|
||||
application is then using select() to wait for traffic (like any sensible app
|
||||
does) and wants to act on the data when select() tells there is something to
|
||||
for example read, what does an application do?
|
||||
|
||||
With our current API, you have to loop over all the channels and read from
|
||||
them to see if they have data. This effectively makes blocking reads
|
||||
impossible. If the app has many channels in a setup like this, it even becomes
|
||||
slow. (The original API had the libssh2_poll_channel_read() and libssh2_poll()
|
||||
to somewhat overcome this hurdle, but they too have pretty much the same
|
||||
problems plus a few others.)
|
||||
|
||||
Traffic in the other direction is similarly limited: the app has to try
|
||||
sending to all channels, even though some of them may very well not accept any
|
||||
data at that point.
|
||||
|
||||
A SOLUTION
|
||||
|
||||
I suggest we introduce two new helper functions:
|
||||
|
||||
libssh2_transport_read()
|
||||
|
||||
- Read "a bunch" of data from the given socket and returns information to the
|
||||
app about what channels that are now readable (ie they will not block when
|
||||
read from). The function can be called over and over and it will repeatedly
|
||||
return info about what channels that are readable at that moment.
|
||||
|
||||
libssh2_transport_write()
|
||||
|
||||
- Returns information about what channels that are writable, in the sense
|
||||
that they have windows set from the remote side that allows data to get
|
||||
sent. Writing to one of those channels will not block. Of course, the
|
||||
underlying socket may only accept a certain amount of data, so at the first
|
||||
short return, nothing more should be attempted to get sent until select()
|
||||
(or equivalent) has been used on the master socket again.
|
||||
|
||||
I haven't yet figured out a sensible API for how these functions should return
|
||||
that info, but if we agree on the general principles I guess we can work that
|
||||
out.
|
||||
|
||||
VOLUNTARY
|
||||
|
||||
I wanted to mention that these two helper functions would not be mandatory
|
||||
in any way. They would just be there for those who want them, and existing
|
||||
programs can remain using the old functions only if they prefer to.
|
||||
|
||||
New SFTP API
|
||||
============
|
||||
|
||||
PURPOSE
|
||||
|
||||
Provide API functions that explicitly tells at once that a (full) SFTP file
|
||||
transfer is wanted, to allow libssh2 to leverage on that knowledge to speed
|
||||
up things internally. It can for example do read ahead, buffer writes (merge
|
||||
small writes into larger chunks), better tune the SSH window and more. This
|
||||
sort of API is already provided for SCP transfers.
|
||||
|
||||
API
|
||||
|
||||
New functions:
|
||||
|
||||
LIBSSH2_SFTP_HANDLE *libssh2_sftp_send(SFTP_SESSION *sftp,
|
||||
uint64_t filesize,
|
||||
char *remote_path,
|
||||
size_t remote_path_len,
|
||||
long mode);
|
||||
|
||||
Tell libssh2 that a local file with a given size is about to get sent to
|
||||
the SFTP server.
|
||||
|
||||
LIBSSH2_SFTP_HANDLE *libssh2_sftp_recv();
|
||||
|
||||
Tell libssh2 that a remote file is requested to get downloaded from the SFTP
|
||||
server.
|
||||
|
||||
Only the setup of the file transfer is different from an application's point
|
||||
of view. Depending on direction of the transfer(s), the following already
|
||||
existing functions should then be used until the transfer is complete:
|
||||
|
||||
libssh2_sftp_read()
|
||||
libssh2_sftp_write()
|
||||
|
||||
HOW TO USE
|
||||
|
||||
1. Setup the transfer using one of the two new functions.
|
||||
|
||||
2. Loop through the reading or writing of data.
|
||||
|
||||
3. Cleanup the transfer
|
||||
@ -0,0 +1,154 @@
|
||||
nghttp2 project was started as a fork of spdylay project [1]. Both
|
||||
projects were started by Tatsuhiro Tsujikawa, who is still the main
|
||||
author of these projects. Meanwhile, we have many contributions, and
|
||||
we are not here without them. We sincerely thank you to all who made
|
||||
a contribution. Here is the all individuals/organizations who
|
||||
contributed to nghttp2 and spdylay project at which we forked. These
|
||||
names are retrieved from git commit log. If you have made a
|
||||
contribution, but you are missing in the list, please let us know via
|
||||
github issues [2].
|
||||
|
||||
[1] https://github.com/tatsuhiro-t/spdylay
|
||||
[2] https://github.com/nghttp2/nghttp2/issues
|
||||
|
||||
--------
|
||||
|
||||
187j3x1
|
||||
Adam Gołębiowski
|
||||
Alek Storm
|
||||
Alex Nalivko
|
||||
Alexandros Konstantinakis-Karmis
|
||||
Alexis La Goutte
|
||||
Amir Livneh
|
||||
Amir Pakdel
|
||||
Anders Bakken
|
||||
Andreas Pohl
|
||||
Andrew Penkrat
|
||||
Andy Davies
|
||||
Angus Gratton
|
||||
Anna Henningsen
|
||||
Ant Bryan
|
||||
Asra Ali
|
||||
Benedikt Christoph Wolters
|
||||
Benjamin Peterson
|
||||
Bernard Spil
|
||||
Brendan Heinonen
|
||||
Brian Card
|
||||
Brian Suh
|
||||
Daniel Bevenius
|
||||
Daniel Evers
|
||||
Daniel Stenberg
|
||||
Dave Reisner
|
||||
David Beitey
|
||||
David Korczynski
|
||||
David Weekly
|
||||
Dimitris Apostolou
|
||||
Dmitri Tikhonov
|
||||
Dmitriy Vetutnev
|
||||
Don
|
||||
Dylan Plecki
|
||||
Etienne Cimon
|
||||
Fabian Möller
|
||||
Fabian Wiesel
|
||||
Fred Sundvik
|
||||
Gabi Davar
|
||||
Gaël PORTAY
|
||||
Geoff Hill
|
||||
George Liu
|
||||
Gitai
|
||||
Google Inc.
|
||||
Hajime Fujita
|
||||
Jacky Tian
|
||||
Jacky_Yin
|
||||
Jacob Champion
|
||||
James M Snell
|
||||
Jan Kundrát
|
||||
Jan-E
|
||||
Janusz Dziemidowicz
|
||||
Jay Satiro
|
||||
Jeff 'Raid' Baitis
|
||||
Jianqing Wang
|
||||
Jim Morrison
|
||||
Josh Braegger
|
||||
José F. Calcerrada
|
||||
Kamil Dudka
|
||||
Kazuho Oku
|
||||
Kenny (kang-yen) Peng
|
||||
Kenny Peng
|
||||
Kit Chan
|
||||
Kyle Schomp
|
||||
LazyHamster
|
||||
Leo Neat
|
||||
Lorenz Nickel
|
||||
Lucas Pardue
|
||||
MATSUMOTO Ryosuke
|
||||
Marc Bachmann
|
||||
Marcelo Trylesinski
|
||||
Matt Rudary
|
||||
Matt Way
|
||||
Michael Kaufmann
|
||||
Mike Conlen
|
||||
Mike Frysinger
|
||||
Mike Lothian
|
||||
Nicholas Hurley
|
||||
Nora Shoemaker
|
||||
Paweł Wegner
|
||||
Pedro Santos
|
||||
Peeyush Aggarwal
|
||||
Peter Wu
|
||||
Piotr Sikora
|
||||
PufferOverflow
|
||||
Raul Gutierrez Segales
|
||||
Remo E
|
||||
Renaud
|
||||
Reza Tavakoli
|
||||
Richard Wolfert
|
||||
Rick Lei
|
||||
Ross Smith II
|
||||
Rudi Heitbaum
|
||||
Ryo Ota
|
||||
Scott Mitchell
|
||||
Sebastiaan Deckers
|
||||
Shelley Vohr
|
||||
Simon Frankenberger
|
||||
Simone Basso
|
||||
Soham Sinha
|
||||
Stefan Eissing
|
||||
Stephen Ludin
|
||||
Sunpoet Po-Chuan Hsieh
|
||||
Svante Signell
|
||||
Syohei YOSHIDA
|
||||
Tapanito
|
||||
Tatsuhiko Kubo
|
||||
Tatsuhiro Tsujikawa
|
||||
Tobias Geerinckx-Rice
|
||||
Tom Harwood
|
||||
Tomas Krizek
|
||||
Tomasz Buchert
|
||||
Tomasz Torcz
|
||||
Vernon Tang
|
||||
Viacheslav Biriukov
|
||||
Viktor Szakats
|
||||
Viktor Szépe
|
||||
Wenfeng Liu
|
||||
William A Rowe Jr
|
||||
Xiaoguang Sun
|
||||
Zhuoyun Wei
|
||||
acesso
|
||||
ayanamist
|
||||
bxshi
|
||||
clemahieu
|
||||
dalf
|
||||
dawg
|
||||
es
|
||||
fangdingjun
|
||||
jwchoi
|
||||
kumagi
|
||||
lhuang04
|
||||
lstefani
|
||||
makovich
|
||||
mod-h2-dev
|
||||
moparisthebest
|
||||
robaho
|
||||
snnn
|
||||
yuuki-kodama
|
||||
@ -0,0 +1,23 @@
|
||||
The MIT License
|
||||
|
||||
Copyright (c) 2012, 2014, 2015, 2016 Tatsuhiro Tsujikawa
|
||||
Copyright (c) 2012, 2014, 2015, 2016 nghttp2 contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
@ -0,0 +1,546 @@
|
||||
commit ed2ccce0e844a128891cfc334afd371371fae639 (HEAD, tag: v1.53.0, origin/master, origin/HEAD, master)
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-05-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-05-10
|
||||
|
||||
Generate .asc files
|
||||
|
||||
commit 7a0e16510a72576cfd6cc3683367297e349e48e4
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-05-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-05-10
|
||||
|
||||
Update manual pages
|
||||
|
||||
commit f62b2b23b1a9ad675ccffbe5f13929ba2f6005a8
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-05-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-05-10
|
||||
|
||||
Bump package and library versions
|
||||
|
||||
commit 5e8904e327351ed5827f346f78b53aa909c721ec
|
||||
Merge: e392729d 26ab7c14
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-29
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-29
|
||||
|
||||
Merge pull request #1902 from nghttp2/bump-neverbleed
|
||||
|
||||
Bump neverbleed
|
||||
|
||||
commit 26ab7c147570c2ca08a22342db68693109efed77
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-29
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-29
|
||||
|
||||
Bump neverbleed
|
||||
|
||||
commit e392729d9f65ab64c1302d0a5e4c564ef22d5952
|
||||
Merge: 88e03cda 0fbfc487
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-29
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-29
|
||||
|
||||
Merge pull request #1901 from nghttp2/zerofill-z_stream
|
||||
|
||||
Initialize z_stream completely with zeros
|
||||
|
||||
commit 0fbfc487168e09adc500f629eacbd17f602a4685
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-29
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-29
|
||||
|
||||
Initialize z_stream completely with zeros
|
||||
|
||||
commit 88e03cdaf0e08edc838e0691a8354cbf096e06c4
|
||||
Merge: 4f27509e 7645ab89
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-26
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-26
|
||||
|
||||
Merge pull request #1900 from nghttp2/nghttpx-send-new-token-on-path-change
|
||||
|
||||
nghttpx: Send NEW_TOKEN on path change
|
||||
|
||||
commit 7645ab89bca97d8d915806481f007136cdd2145d
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-26
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-26
|
||||
|
||||
nghttpx: Send NEW_TOKEN on path change
|
||||
|
||||
commit 4f27509e674b5c33441817952992df8d2d9bf0ad
|
||||
Merge: 757bc3cb 7a4e706b
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-26
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-26
|
||||
|
||||
Merge pull request #1899 from nghttp2/bump-ngtcp2
|
||||
|
||||
Bump ngtcp2
|
||||
|
||||
commit 7a4e706b4483af72f97d5ff387e1550df1ae728f
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-23
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-26
|
||||
|
||||
Bump ngtcp2
|
||||
|
||||
commit 757bc3cbe931e22f19521a34e3b69e7b22a1b3ea
|
||||
Merge: cc1402bf 2ee33fe8
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-22
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-22
|
||||
|
||||
Merge pull request #1898 from nghttp2/sfparse
|
||||
|
||||
Import ngtcp2/sfparse, Structured Field Values parser
|
||||
|
||||
commit 2ee33fe8cdc034f0a711dabb7e11c6f857197688
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-22
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-22
|
||||
|
||||
Import ngtcp2/sfparse, Structured Field Values parser
|
||||
|
||||
commit cc1402bf441cad6277a6e3282b74a4060f7733f9
|
||||
Merge: 56fcb73c 70690ce0
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-22
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-22
|
||||
|
||||
Merge pull request #1897 from nghttp2/lazy-initialize-map-table
|
||||
|
||||
Initialize map table lazily
|
||||
|
||||
commit 70690ce010391c02acdf7dba4a23d7701e768d04
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-22
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-22
|
||||
|
||||
Initialize map table lazily
|
||||
|
||||
commit 56fcb73cc4cab6032c191d931f35bad55774624b
|
||||
Merge: 51b0288f 84eecc01
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-04-21
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-04-21
|
||||
|
||||
Merge pull request #1896 from nghttp2/msvc-build-check
|
||||
|
||||
Msvc build check
|
||||
|
||||
commit 84eecc015c0e1f876c7ce7b71255b4b2ca0b3c24
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-21
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-21
|
||||
|
||||
Fix implicit conversion warnings
|
||||
|
||||
commit 4bb4ff06e37c03128792a575c5bc09d62a639827
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-21
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-21
|
||||
|
||||
Fix function signature
|
||||
|
||||
commit 8610758e14ed66672c820e4acd432dee52863138
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-21
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-21
|
||||
|
||||
Include stdio.h to workaround error due to legacy CUnit snprintf macro
|
||||
|
||||
commit caf9d3abd53772e796fde0926e793fb82fe71807
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-04-21
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-04-21
|
||||
|
||||
Run msvc build check
|
||||
|
||||
commit 51b0288f5d18d72cf143ed5e3f7016cd77879ccd
|
||||
Merge: 251d3f87 7fb488be
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Merge pull request #1892 from nghttp2/nghttpx-h3-write-event
|
||||
|
||||
nghttpx: write watcher should only be started upon blocking write
|
||||
|
||||
commit 7fb488be15e42ffffa6f90fe4158c28572029f7d
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
nghttpx: write watcher should only be started upon blocking write
|
||||
|
||||
commit 251d3f8743518db8ef89da61bc3d4a8c35d71a6f
|
||||
Merge: edfc6a85 3676eb91
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Merge pull request #1891 from nghttp2/bump-ngtcp2
|
||||
|
||||
Bump ngtcp2 to v0.14.0
|
||||
|
||||
commit 3676eb91e31b89d1c68d1125eff211bc7f9009fd
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Bump ngtcp2 to v0.14.0
|
||||
|
||||
commit edfc6a8530b40ad3bfc6db666528b2c89ae8a248
|
||||
Merge: 7efbcfec 448c68ef
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-16
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-16
|
||||
|
||||
Merge pull request #1888 from nghttp2/fix-macos-setup
|
||||
|
||||
Add missing if condition to MacOS setup
|
||||
|
||||
commit 448c68ef0182ee4f1342bdcbaa048a9274ee5e26
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-16
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-16
|
||||
|
||||
Add missing if condition to MacOS setup
|
||||
|
||||
commit 7efbcfecff539fe114c969b25789c7b7ffb2127e
|
||||
Merge: c460afc2 de743aad
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-16
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-16
|
||||
|
||||
Merge pull request #1887 from nghttp2/add-verify_hostname-tests
|
||||
|
||||
Add verify_hostname tests
|
||||
|
||||
commit de743aad4af61f6ddb2eae59eb24ee4ceb9b7687
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-15
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-15
|
||||
|
||||
Add verify_hostname tests
|
||||
|
||||
commit c460afc2d9fdefc39e2566f7fdb3e8f1c220ef26
|
||||
Merge: 83993b1d c03cd592
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-15
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-15
|
||||
|
||||
Merge pull request #1886 from nghttp2/fix-compile-errors
|
||||
|
||||
Fix compile errors with clang-15
|
||||
|
||||
commit c03cd59274e6cd7b2cad4e6e5b05e37eca84389c
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-15
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-15
|
||||
|
||||
Fix compile errors with clang-15
|
||||
|
||||
commit 83993b1dbf499cc7b83ad8d6ba099906d52163a9
|
||||
Merge: ef7bb8ef cc144000
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-15
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-15
|
||||
|
||||
Merge pull request #1885 from nghttp2/nghttpx-fix-numeric-hostname-verify
|
||||
|
||||
nghttpx: Fix numeric hostname verification
|
||||
|
||||
commit cc144000965fef3e861a6effb517b90d2a42c63e
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-15
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-15
|
||||
|
||||
nghttpx: Fix numeric hostname verification
|
||||
|
||||
commit ef7bb8ef9fd680bf9eecf2dd8ac710cedc195e6d
|
||||
Merge: b8cb6efb bc6814eb
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-11
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-11
|
||||
|
||||
Merge pull request #1881 from nghttp2/nghttpx-fix-heap-use-after-free
|
||||
|
||||
nghttpx: Fix heap-use-after-free
|
||||
|
||||
commit bc6814eb5b3ac76b0a8e02f6b2c3bffde4f63749
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-11
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-11
|
||||
|
||||
nghttpx: Fix heap-use-after-free
|
||||
|
||||
Fix heap-use-after-free introduced by
|
||||
ddb667e8bff8fbdd1576f7637fc5d18bf5da9eb7.
|
||||
|
||||
commit b8cb6efb375ac12cb4485cac49ec1556cb3e8210
|
||||
Merge: 7628879e 83af9b50
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-11
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-11
|
||||
|
||||
Merge pull request #1880 from nghttp2/nghttpx-tweak-worker-process-handling
|
||||
|
||||
Nghttpx tweak worker process handling
|
||||
|
||||
commit 83af9b504ba35ec4f7ee0991ff0affc546210674
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-10
|
||||
|
||||
nghttpx: Wait for new worker process to be ready
|
||||
|
||||
Wait for new worker process to be ready before sending graceful
|
||||
shutdown event to the existing worker processes to avoid down time
|
||||
during configuration reload.
|
||||
|
||||
commit ddb667e8bff8fbdd1576f7637fc5d18bf5da9eb7
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-10
|
||||
|
||||
nghttpx: Signal watcher should be global, not per WorkerProcess
|
||||
|
||||
commit 704153e4cba43846a66fe83f72d6df561d6b78df
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-10
|
||||
|
||||
nghttpx: Wait for all worker processes to stop before quit
|
||||
|
||||
When quitting, wait for all worker processes to stop. Previously, we
|
||||
just exit the event loop when the last process exits. But the because
|
||||
of the bug, it does not work as intended.
|
||||
|
||||
commit 39f6c081870dcb2767aa6ef11eb5a4392b226440
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-10
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-10
|
||||
|
||||
nghttpx: Update LogConfig::pid on fork
|
||||
|
||||
commit 7628879e7987efe250aaa31d7a9ad5c36d0c1c33
|
||||
Merge: 1e47a198 20173a59
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-08
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-08
|
||||
|
||||
Merge pull request #1879 from nghttp2/workflow-permissions
|
||||
|
||||
Set workflow permissions
|
||||
|
||||
commit 20173a59f02ca576323401fed5528713feacc1a2
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-08
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-08
|
||||
|
||||
Set workflow permissions
|
||||
|
||||
commit 1e47a1984de6addcd23e319947a416b47bf5954e
|
||||
Merge: 14cc308d 14268ccb
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Merge pull request #1877 from nghttp2/sphinx-doc-enum
|
||||
|
||||
sphinx-doc understands :enum:
|
||||
|
||||
commit 14268ccbaa1cf7cafe1be79f6d1e07c66e87f23a
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
sphinx-doc understands :enum:
|
||||
|
||||
commit 14cc308d537ed21b1bfc857761af000b673c86e7
|
||||
Merge: 1c62a2a9 bb024e3d
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-26
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
Merge pull request #1874 from nghttp2/nghttpx-llhttp-resume-after-upgrade
|
||||
|
||||
nghttpx: Fix bug that causes 400 response after upgrade failure
|
||||
|
||||
commit bb024e3d82d68497493a0a54532aad7e1499df43
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-26
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
nghttpx: Fix bug that causes 400 response after upgrade failure
|
||||
|
||||
commit 1c62a2a9238e0a4980a058d01e0866fcdbef6fcb
|
||||
Merge: dc74b50c 094c60db
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-26
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
Merge pull request #1873 from nghttp2/bump-go-mod
|
||||
|
||||
Bump go modules
|
||||
|
||||
commit 094c60db890625ac41275a5a35ab3e973f5ece74
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-23
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
Bump go modules
|
||||
|
||||
commit dc74b50cc92651819e20761bc4e48a887642ee28
|
||||
Merge: a1c7e507 5cd87eae
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-26
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
Merge pull request #1872 from nghttp2/bump-mruby
|
||||
|
||||
Bump mruby to 3.2.0
|
||||
|
||||
commit 5cd87eae22d2a81d5e1ee21b6a28d645455fb506
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-26
|
||||
|
||||
Bump mruby to 3.2.0
|
||||
|
||||
commit a1c7e507aa3a75b1f61f3d69901a127487cd923f
|
||||
Merge: b400bb5c 9526e2ff
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-25
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-25
|
||||
|
||||
Merge pull request #1871 from nghttp2/nghttpx-h3-graceful-shutdown
|
||||
|
||||
nghttpx: Gracefully shutdown HTTP/3 connection
|
||||
|
||||
commit 9526e2ff80455e0455a6636988dc1f2957012f72
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-23
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
nghttpx: Gracefully shutdown HTTP/3 connection
|
||||
|
||||
commit b400bb5c15471435abb5ad3a9723b5bfac7d61c3
|
||||
Merge: 878de84f 89cb55a6
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
Merge pull request #1870 from nghttp2/bump-nghttp3
|
||||
|
||||
Bump nghttp3 to v0.9.0
|
||||
|
||||
commit 89cb55a62f369bb076d048f256dba0091dec0215
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
Bump nghttp3 to v0.9.0
|
||||
|
||||
commit 878de84feb1b4944755972d5543ab64f00f8e12f
|
||||
Merge: 1eb91d2e 9862a86b
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
Merge pull request #1869 from nghttp2/build-cache
|
||||
|
||||
Cache dependencies to speed up workflow builds
|
||||
|
||||
commit 9862a86b3127e1f2216a0c2f39b866f23127dd32
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
Cache dependencies to speed up workflow builds
|
||||
|
||||
commit 1eb91d2e50d98e30fde01f3d95786ec69ebc36b5
|
||||
Merge: 5cb908b6 50fbb764
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-02-23
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-02-23
|
||||
|
||||
Merge pull request #1867 from nghttp2/bump-go-mod
|
||||
|
||||
Bump golang.org/x/net to v0.7.0
|
||||
|
||||
commit 50fbb7645462e1dd77c596fec8f132bc8b0cb9ba
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-23
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-23
|
||||
|
||||
Bump golang.org/x/net to v0.7.0
|
||||
|
||||
commit 5cb908b62583b52c0b905b41ef96aa3fd58f179c
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-13
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-13
|
||||
|
||||
Bump package version
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,19 @@
|
||||
Alexis La Goutte
|
||||
Amir Livneh
|
||||
Bryan Call
|
||||
Cheng Zhao
|
||||
Daniel Bevenius
|
||||
Daniel Stenberg
|
||||
Dimitris Apostolou
|
||||
Don
|
||||
James M Snell
|
||||
Javier Blazquez
|
||||
Li Xinwei
|
||||
Ondřej Koláček
|
||||
Peter Wu
|
||||
Tatsuhiro Tsujikawa
|
||||
Tim Gates
|
||||
Toni Uhlig
|
||||
Valère Plantevin
|
||||
Viktor Szakats
|
||||
Your Name
|
||||
@ -0,0 +1,22 @@
|
||||
The MIT License
|
||||
|
||||
Copyright (c) 2019 nghttp3 contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
@ -0,0 +1,229 @@
|
||||
commit 2eda009319eceec3544d7a164b52be873a928ac0 (HEAD, tag: v0.10.0, origin/main, origin/HEAD, main)
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Bump package and library versions
|
||||
|
||||
commit 0695b8d59aa160c1ae62dde14dc91f3f67a80c07
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Update AUTHORS
|
||||
|
||||
commit d7937156ccfa307e6a6127d5c158feb5075c3dd0
|
||||
Merge: caab8b0 a1ed87d
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Merge pull request #122 from ngtcp2/update-sfparse
|
||||
|
||||
Update sfparse
|
||||
|
||||
commit a1ed87d46b5bfacd3167597b0e8cdee30b8868bf
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-25
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-25
|
||||
|
||||
Update sfparse
|
||||
|
||||
commit caab8b0126a643f13eed4a31b8fbe4dc13bc24bd
|
||||
Merge: f2c17d5 9a7549c
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-19
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-19
|
||||
|
||||
Merge pull request #121 from ngtcp2/rename-object-version-macros
|
||||
|
||||
Rename object version macros
|
||||
|
||||
commit 9a7549c8528893eef793d2d10551323818e36955
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-19
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-19
|
||||
|
||||
Rename object version macros
|
||||
|
||||
commit f2c17d53e6f15e6d87d598bb546266d79eaca3f2
|
||||
Merge: cbd68ba a4cdce4
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-08
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-08
|
||||
|
||||
Merge pull request #119 from ngtcp2/workflow-permissions
|
||||
|
||||
Set workflow permissions
|
||||
|
||||
commit a4cdce46c4a2fa3ca6de0d0380529ceeb31248cf
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-08
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-08
|
||||
|
||||
Set workflow permissions
|
||||
|
||||
commit cbd68ba682a808964734d66672c04a330376ee72
|
||||
Merge: 895e435 a71b324
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-07
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-07
|
||||
|
||||
Merge pull request #118 from ngtcp2/update-sfparse
|
||||
|
||||
Update sfparse
|
||||
|
||||
commit a71b324fbf2df0a982bb26d49522e1803c67bde5
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-07
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-07
|
||||
|
||||
Update sfparse
|
||||
|
||||
Update sfparse to 6e314ece1a1374abcb0bbd1ba1c8db3c3ccad6ff
|
||||
|
||||
commit 895e435b2b41913b3402a5c9f25a18fbf1f78f22
|
||||
Merge: ccf53ab 0608434
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Merge pull request #117 from ngtcp2/update-sfparse
|
||||
|
||||
Update sfparse
|
||||
|
||||
commit 06084349b3b7831495b551e9a449d62560772658
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Update sfparse
|
||||
|
||||
Update sfparse to d35c23fdd896689ca59b5c013dfd798bd03a265b
|
||||
|
||||
commit ccf53abc7602824390739cd8d530fb6ebd4af77a
|
||||
Merge: bec6ddf 6cd4264
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Merge pull request #116 from ngtcp2/sphinx-doc-enum
|
||||
|
||||
sphinx-doc understands :enum:
|
||||
|
||||
commit 6cd4264c01cecd7dc493cfc2d5433fedc97e4a8a
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
sphinx-doc understands :enum:
|
||||
|
||||
commit bec6ddf1c6042bcdd412140fb1485e09117168d7
|
||||
Merge: 6b9c3f0 b9cab77
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Merge pull request #115 from ngtcp2/send-nonzero-h3-datagram
|
||||
|
||||
Only send SETTINGS_H3_DATAGRAM when it is enabled
|
||||
|
||||
commit b9cab77009773ca88860d4601121305c0b09fb99
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-06
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-06
|
||||
|
||||
Only send SETTINGS_H3_DATAGRAM when it is enabled
|
||||
|
||||
commit 6b9c3f00488265f320da3845daf8ebff3f3eb6e2
|
||||
Merge: da011b9 ef82edf
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
Merge pull request #114 from ngtcp2/settings-h3_datagram
|
||||
|
||||
Send and receive SETTINGS_H3_DATAGRAM
|
||||
|
||||
commit ef82edf5429bcb66c3c4702a02057d001fa2b7a7
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
Send and receive SETTINGS_H3_DATAGRAM
|
||||
|
||||
commit da011b906eb5dcf98f71c895b31d79f9c531b754
|
||||
Merge: 98d91a8 8f9f960
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
Merge pull request #113 from ngtcp2/sfparse
|
||||
|
||||
Adopt sfparse to parse Structured Field Values
|
||||
|
||||
commit 8f9f9606324fb6a4ca84e2b6ffa11c4b2e9dfca2
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
Adopt sfparse to parse Structured Field Values
|
||||
|
||||
Import sfparse at c3776f3337aed85ea321f39e04f9921adb139dd0
|
||||
|
||||
commit 98d91a84caf8cf59caa9a7f50ca2ff2bf3c94123
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
clang-format
|
||||
|
||||
commit 439e5c4d879d2e5cea797dc5eae3a0872c10727a
|
||||
Merge: 5ce108b 0b3b1ec
|
||||
Author: Tatsuhiro Tsujikawa <404610+tatsuhiro-t@users.noreply.github.com>
|
||||
AuthorDate: 2023-03-05
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-05
|
||||
|
||||
Merge pull request #112 from zcbenz/patch-1
|
||||
|
||||
Clang has __popcnt for ARM
|
||||
|
||||
commit 0b3b1ec5d888d9b658d9d2750f82cdcc7e14cb68
|
||||
Author: Cheng Zhao <zcbenz@gmail.com>
|
||||
AuthorDate: 2023-03-03
|
||||
Commit: GitHub <noreply@github.com>
|
||||
CommitDate: 2023-03-03
|
||||
|
||||
Clang has __popcnt for ARM
|
||||
|
||||
When binding on Windows with clang for ARM targets, `__popcnt` is defined.
|
||||
|
||||
commit 5ce108b9917cd2f7a5cce83f21a64c08a19da221
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-02-24
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-02-24
|
||||
|
||||
Bump package version
|
||||
@ -0,0 +1,42 @@
|
||||
nghttp3
|
||||
=======
|
||||
|
||||
nghttp3 is an implementation of `RFC 9114
|
||||
<https://datatracker.ietf.org/doc/html/rfc9114>`_ HTTP/3 mapping over
|
||||
QUIC and `RFC 9204 <https://datatracker.ietf.org/doc/html/rfc9204>`_
|
||||
QPACK in C.
|
||||
|
||||
It does not depend on any particular QUIC transport implementation.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
`Online documentation <https://nghttp2.org/nghttp3/>`_ is available.
|
||||
|
||||
HTTP/3
|
||||
------
|
||||
|
||||
This library implements `RFC 9114
|
||||
<https://datatracker.ietf.org/doc/html/rfc9114>`_ HTTP/3. It does not
|
||||
support server push.
|
||||
|
||||
The following extensions have been implemented:
|
||||
|
||||
- `Extensible Prioritization Scheme for HTTP
|
||||
<https://datatracker.ietf.org/doc/html/rfc9218>`_
|
||||
- `Bootstrapping WebSockets with HTTP/3
|
||||
<https://datatracker.ietf.org/doc/html/rfc9220>`_
|
||||
|
||||
QPACK
|
||||
-----
|
||||
|
||||
This library implements `RFC 9204
|
||||
<https://datatracker.ietf.org/doc/html/rfc9204>`_ QPACK. It supports
|
||||
dynamic table.
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
The MIT License
|
||||
|
||||
Copyright (c) 2019 nghttp3 contributors
|
||||
@ -0,0 +1,46 @@
|
||||
Alexis La Goutte
|
||||
Amir Livneh
|
||||
Anna Henningsen
|
||||
Bryan Call
|
||||
Cheng Zhao
|
||||
Daan De Meyer
|
||||
Daiki Ueno
|
||||
Daniel Bevenius
|
||||
Daniel Stenberg
|
||||
Dave Reisner
|
||||
Don
|
||||
Frédéric Lécaille
|
||||
Félix Dagenais
|
||||
James M Snell
|
||||
Javier Blazquez
|
||||
Jay Satiro
|
||||
Jean-Philippe Boivin
|
||||
Jiawen Geng
|
||||
Junqi Wang
|
||||
Ken-ichi ICHINO
|
||||
Liang Ma
|
||||
Mark Chiou
|
||||
Martin Thomson
|
||||
NKTelnet
|
||||
Natris
|
||||
Patrick Griffis
|
||||
Peter Wu
|
||||
Samuel Henrique
|
||||
Stefan Eissing
|
||||
Stefan Eissing
|
||||
Tatsuhiro Tsujikawa
|
||||
Tim Gates
|
||||
Tomas Mraz
|
||||
Toni Uhlig
|
||||
Valère Plantevin
|
||||
Victor Loh
|
||||
Viktor Szakats
|
||||
Zizhong Zhang
|
||||
flx413
|
||||
hondaxiao
|
||||
junqiw
|
||||
msoxzw
|
||||
nickfajones
|
||||
rhoxn
|
||||
scw00
|
||||
shibin k v
|
||||
@ -0,0 +1,22 @@
|
||||
The MIT License
|
||||
|
||||
Copyright (c) 2016 ngtcp2 contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
@ -0,0 +1,34 @@
|
||||
commit 7c9f32ca7d905ba96b342e2ceebe7eb68519d9c0 (HEAD, tag: v0.14.1, origin/release-0.14, origin/HEAD, release-0.14)
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-30
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-30
|
||||
|
||||
Bump package version
|
||||
|
||||
commit 023296e05581a877b5cfbb8ecfd587838e813a01
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-30
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-30
|
||||
|
||||
Amend c6f924715aad8844ab7a48dbf7ce55945b76f548
|
||||
|
||||
commit c6f924715aad8844ab7a48dbf7ce55945b76f548
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-30
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-30
|
||||
|
||||
Pin nghttp3 version to fix build issue
|
||||
|
||||
commit fad523c79c8166db2d0a8fb5dc095cf84e2ee7e2
|
||||
Author: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
AuthorDate: 2023-03-26
|
||||
Commit: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
|
||||
CommitDate: 2023-03-30
|
||||
|
||||
client: Fix bug that nghttp3_conn is not initialized
|
||||
|
||||
Fix bug that nghttp3_conn is not initialized when resuming session
|
||||
without sending early data.
|
||||
@ -0,0 +1,258 @@
|
||||
ngtcp2
|
||||
======
|
||||
|
||||
"Call it TCP/2. One More Time."
|
||||
|
||||
ngtcp2 project is an effort to implement `RFC9000
|
||||
<https://datatracker.ietf.org/doc/html/rfc9000>`_ QUIC protocol.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
`Online documentation <https://nghttp2.org/ngtcp2/>`_ is available.
|
||||
|
||||
Public test server
|
||||
------------------
|
||||
|
||||
The following endpoints are available to try out ngtcp2
|
||||
implementation:
|
||||
|
||||
- https://nghttp2.org:4433
|
||||
- https://nghttp2.org:4434 (requires address validation token)
|
||||
- https://nghttp2.org (powered by `nghttpx
|
||||
<https://nghttp2.org/documentation/nghttpx.1.html>`_)
|
||||
|
||||
This endpoints sends Alt-Svc header field to clients if it is
|
||||
accessed via HTTP/1.1 or HTTP/2 to tell them that HTTP/3 is
|
||||
available at UDP 443.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
The libngtcp2 C library itself does not depend on any external
|
||||
libraries. The example client, and server are written in C++20, and
|
||||
should compile with the modern C++ compilers (e.g., clang >= 11.0, or
|
||||
gcc >= 11.0).
|
||||
|
||||
The following packages are required to configure the build system:
|
||||
|
||||
- pkg-config >= 0.20
|
||||
- autoconf
|
||||
- automake
|
||||
- autotools-dev
|
||||
- libtool
|
||||
|
||||
libngtcp2 uses cunit for its unit test frame work:
|
||||
|
||||
- cunit >= 2.1
|
||||
|
||||
To build sources under the examples directory, libev and nghttp3 are
|
||||
required:
|
||||
|
||||
- libev
|
||||
- `nghttp3 <https://github.com/ngtcp2/nghttp3>`_ for HTTP/3
|
||||
|
||||
ngtcp2 crypto helper library, and client and server under examples
|
||||
directory require at least one of the following TLS backends:
|
||||
|
||||
- `OpenSSL with QUIC support
|
||||
<https://github.com/quictls/openssl/tree/OpenSSL_1_1_1t+quic>`_
|
||||
- GnuTLS >= 3.7.2
|
||||
- BoringSSL (commit 74646566e93de7551bfdfc5f49de7462f13d1d05)
|
||||
- Picotls (commit 61228171836561b5f6feee5bf0ad81414d47e748)
|
||||
- wolfSSL >= 5.5.0
|
||||
|
||||
Build from git
|
||||
--------------
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ git clone --depth 1 -b OpenSSL_1_1_1t+quic https://github.com/quictls/openssl
|
||||
$ cd openssl
|
||||
$ # For Linux
|
||||
$ ./config enable-tls1_3 --prefix=$PWD/build
|
||||
$ make -j$(nproc)
|
||||
$ make install_sw
|
||||
$ cd ..
|
||||
$ git clone https://github.com/ngtcp2/nghttp3
|
||||
$ cd nghttp3
|
||||
$ autoreconf -i
|
||||
$ ./configure --prefix=$PWD/build --enable-lib-only
|
||||
$ make -j$(nproc) check
|
||||
$ make install
|
||||
$ cd ..
|
||||
$ git clone https://github.com/ngtcp2/ngtcp2
|
||||
$ cd ngtcp2
|
||||
$ autoreconf -i
|
||||
$ # For Mac users who have installed libev with MacPorts, append
|
||||
$ # ',-L/opt/local/lib' to LDFLAGS, and also pass
|
||||
$ # CPPFLAGS="-I/opt/local/include" to ./configure.
|
||||
$ # For OpenSSL >= v3.0.0, replace "openssl/build/lib" with
|
||||
$ # "openssl/build/lib64".
|
||||
$ ./configure PKG_CONFIG_PATH=$PWD/../openssl/build/lib/pkgconfig:$PWD/../nghttp3/build/lib/pkgconfig LDFLAGS="-Wl,-rpath,$PWD/../openssl/build/lib"
|
||||
$ make -j$(nproc) check
|
||||
|
||||
Client/Server
|
||||
-------------
|
||||
|
||||
After successful build, the client and server executable should be
|
||||
found under examples directory. They talk HTTP/3.
|
||||
|
||||
Client
|
||||
~~~~~~
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ examples/client [OPTIONS] <HOST> <PORT> [<URI>...]
|
||||
|
||||
The notable options are:
|
||||
|
||||
- ``-d``, ``--data=<PATH>``: Read data from <PATH> and send it to a
|
||||
peer.
|
||||
|
||||
Server
|
||||
~~~~~~
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ examples/server [OPTIONS] <ADDR> <PORT> <PRIVATE_KEY_FILE> <CERTIFICATE_FILE>
|
||||
|
||||
The notable options are:
|
||||
|
||||
- ``-V``, ``--validate-addr``: Enforce stateless address validation.
|
||||
|
||||
H09client/H09server
|
||||
-------------------
|
||||
|
||||
There are h09client and h09server which speak HTTP/0.9. They are
|
||||
written just for `quic-interop-runner
|
||||
<https://github.com/marten-seemann/quic-interop-runner>`_. They share
|
||||
the basic functionalities with HTTP/3 client and server but have less
|
||||
functions (e.g., h09client does not have a capability to send request
|
||||
body, and h09server does not understand numeric request path, like
|
||||
/1000).
|
||||
|
||||
Resumption and 0-RTT
|
||||
--------------------
|
||||
|
||||
In order to resume a session, a session ticket, and a transport
|
||||
parameters must be fetched from server. First, run examples/client
|
||||
with --session-file, and --tp-file options which specify a path to
|
||||
session ticket, and transport parameter files respectively to save
|
||||
them locally.
|
||||
|
||||
Once these files are available, run examples/client with the same
|
||||
arguments again. You will see that session is resumed in your log if
|
||||
resumption succeeds. Resuming session makes server's first Handshake
|
||||
packet pretty small because it does not send its certificates.
|
||||
|
||||
To send 0-RTT data, after making sure that resumption works, use -d
|
||||
option to specify a file which contains data to send.
|
||||
|
||||
Token (Not something included in Retry packet)
|
||||
----------------------------------------------
|
||||
|
||||
QUIC server might send a token to client after connection has been
|
||||
established. Client can send this token in subsequent connection to
|
||||
the server. Server verifies the token and if it succeeds, the address
|
||||
validation completes and lifts some restrictions on server which might
|
||||
speed up transfer. In order to save and/or load a token,
|
||||
use --token-file option of examples/client. The given file is
|
||||
overwritten if it already exists when storing a token.
|
||||
|
||||
Crypto helper library
|
||||
---------------------
|
||||
|
||||
In order to make TLS stack integration less painful, we provide a
|
||||
crypto helper library which offers the basic crypto operations.
|
||||
|
||||
The header file exists under crypto/includes/ngtcp2 directory.
|
||||
|
||||
Each library file is built for a particular TLS backend. The
|
||||
available crypto helper libraries are:
|
||||
|
||||
- libngtcp2_crypto_openssl: Use OpenSSL as TLS backend
|
||||
- libngtcp2_crypto_gnutls: Use GnuTLS as TLS backend
|
||||
- libngtcp2_crypto_boringssl: Use BoringSSL as TLS backend
|
||||
- libngtcp2_crypto_picotls: Use Picotls as TLS backend
|
||||
- libngtcp2_crypto_wolfssl: Use wolfSSL as TLS backend
|
||||
|
||||
Because BoringSSL and Picotls are an unversioned product, we only
|
||||
tested their particular revision. See Requirements section above.
|
||||
|
||||
We use Picotls with OpenSSL as crypto backend. It does not work with
|
||||
OpenSSL >= 3.0.0.
|
||||
|
||||
The examples directory contains client and server that are linked to
|
||||
those crypto helper libraries and TLS backends. They are only built
|
||||
if their corresponding crypto helper library is built:
|
||||
|
||||
- client: OpenSSL client
|
||||
- server: OpenSSL server
|
||||
- gtlsclient: GnuTLS client
|
||||
- gtlsserver: GnuTLS server
|
||||
- bsslclient: BoringSSL client
|
||||
- bsslserver: BoringSSL server
|
||||
- ptlsclient: Picotls client
|
||||
- ptlsserver: Picotls server
|
||||
- wsslclient: wolfSSL client
|
||||
- wsslserver: wolfSSL server
|
||||
|
||||
QUIC protocol extensions
|
||||
-------------------------
|
||||
|
||||
The library implements the following QUIC protocol extensions:
|
||||
|
||||
- `An Unreliable Datagram Extension to QUIC
|
||||
<https://datatracker.ietf.org/doc/html/rfc9221>`_
|
||||
- `Greasing the QUIC Bit
|
||||
<https://datatracker.ietf.org/doc/html/rfc9287>`_
|
||||
- `Compatible Version Negotiation for QUIC
|
||||
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation>`_
|
||||
- `QUIC Version 2
|
||||
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-v2>`_
|
||||
|
||||
Configuring Wireshark for QUIC
|
||||
------------------------------
|
||||
|
||||
`Wireshark <https://www.wireshark.org/download.html>`_ can be configured to
|
||||
analyze QUIC traffic using the following steps:
|
||||
|
||||
1. Set *SSLKEYLOGFILE* environment variable:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ export SSLKEYLOGFILE=quic_keylog_file
|
||||
|
||||
2. Set the port that QUIC uses
|
||||
|
||||
Go to *Preferences->Protocols->QUIC* and set the port the program
|
||||
listens to. In the case of the example application this would be
|
||||
the port specified on the command line.
|
||||
|
||||
3. Set Pre-Master-Secret logfile
|
||||
|
||||
Go to *Preferences->Protocols->TLS* and set the *Pre-Master-Secret
|
||||
log file* to the same value that was specified for *SSLKEYLOGFILE*.
|
||||
|
||||
4. Choose the correct network interface for capturing
|
||||
|
||||
Make sure you choose the correct network interface for
|
||||
capturing. For example, if using localhost choose the *loopback*
|
||||
network interface on macos.
|
||||
|
||||
5. Create a filter
|
||||
|
||||
Create A filter for the udp.port and set the port to the port the
|
||||
application is listening to. For example:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
udp.port == 7777
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
The MIT License
|
||||
|
||||
Copyright (c) 2016 ngtcp2 contributors
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,6 @@
|
||||
Frequently Asked Questions (FAQ)
|
||||
================================
|
||||
|
||||
The [Frequently Asked Questions][FAQ] are now maintained on the OpenSSL homepage.
|
||||
|
||||
[FAQ]: https://www.openssl.org/docs/faq.html
|
||||
@ -0,0 +1,177 @@
|
||||
|
||||
Apache License
|
||||
Version 2.0, January 2004
|
||||
https://www.apache.org/licenses/
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
|
||||
1. Definitions.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,224 @@
|
||||
Welcome to the OpenSSL Project
|
||||
==============================
|
||||
|
||||
[![openssl logo]][www.openssl.org]
|
||||
|
||||
[![github actions ci badge]][github actions ci]
|
||||
[![appveyor badge]][appveyor jobs]
|
||||
|
||||
OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit
|
||||
for the Transport Layer Security (TLS) protocol formerly known as the
|
||||
Secure Sockets Layer (SSL) protocol. The protocol implementation is based
|
||||
on a full-strength general purpose cryptographic library, which can also
|
||||
be used stand-alone.
|
||||
|
||||
OpenSSL is descended from the SSLeay library developed by Eric A. Young
|
||||
and Tim J. Hudson.
|
||||
|
||||
The official Home Page of the OpenSSL Project is [www.openssl.org].
|
||||
|
||||
Table of Contents
|
||||
=================
|
||||
|
||||
- [Overview](#overview)
|
||||
- [Download](#download)
|
||||
- [Build and Install](#build-and-install)
|
||||
- [Documentation](#documentation)
|
||||
- [License](#license)
|
||||
- [Support](#support)
|
||||
- [Contributing](#contributing)
|
||||
- [Legalities](#legalities)
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The OpenSSL toolkit includes:
|
||||
|
||||
- **libssl**
|
||||
an implementation of all TLS protocol versions up to TLSv1.3 ([RFC 8446]).
|
||||
|
||||
- **libcrypto**
|
||||
a full-strength general purpose cryptographic library. It constitutes the
|
||||
basis of the TLS implementation, but can also be used independently.
|
||||
|
||||
- **openssl**
|
||||
the OpenSSL command line tool, a swiss army knife for cryptographic tasks,
|
||||
testing and analyzing. It can be used for
|
||||
- creation of key parameters
|
||||
- creation of X.509 certificates, CSRs and CRLs
|
||||
- calculation of message digests
|
||||
- encryption and decryption
|
||||
- SSL/TLS client and server tests
|
||||
- handling of S/MIME signed or encrypted mail
|
||||
- and more...
|
||||
|
||||
Download
|
||||
========
|
||||
|
||||
For Production Use
|
||||
------------------
|
||||
|
||||
Source code tarballs of the official releases can be downloaded from
|
||||
[www.openssl.org/source](https://www.openssl.org/source).
|
||||
The OpenSSL project does not distribute the toolkit in binary form.
|
||||
|
||||
However, for a large variety of operating systems precompiled versions
|
||||
of the OpenSSL toolkit are available. In particular on Linux and other
|
||||
Unix operating systems it is normally recommended to link against the
|
||||
precompiled shared libraries provided by the distributor or vendor.
|
||||
|
||||
For Testing and Development
|
||||
---------------------------
|
||||
|
||||
Although testing and development could in theory also be done using
|
||||
the source tarballs, having a local copy of the git repository with
|
||||
the entire project history gives you much more insight into the
|
||||
code base.
|
||||
|
||||
The official OpenSSL Git Repository is located at [git.openssl.org].
|
||||
There is a GitHub mirror of the repository at [github.com/openssl/openssl],
|
||||
which is updated automatically from the former on every commit.
|
||||
|
||||
A local copy of the Git Repository can be obtained by cloning it from
|
||||
the original OpenSSL repository using
|
||||
|
||||
git clone git://git.openssl.org/openssl.git
|
||||
|
||||
or from the GitHub mirror using
|
||||
|
||||
git clone https://github.com/openssl/openssl.git
|
||||
|
||||
If you intend to contribute to OpenSSL, either to fix bugs or contribute
|
||||
new features, you need to fork the OpenSSL repository openssl/openssl on
|
||||
GitHub and clone your public fork instead.
|
||||
|
||||
git clone https://github.com/yourname/openssl.git
|
||||
|
||||
This is necessary, because all development of OpenSSL nowadays is done via
|
||||
GitHub pull requests. For more details, see [Contributing](#contributing).
|
||||
|
||||
Build and Install
|
||||
=================
|
||||
|
||||
After obtaining the Source, have a look at the [INSTALL](INSTALL.md) file for
|
||||
detailed instructions about building and installing OpenSSL. For some
|
||||
platforms, the installation instructions are amended by a platform specific
|
||||
document.
|
||||
|
||||
* [Notes for UNIX-like platforms](NOTES-UNIX.md)
|
||||
* [Notes for Android platforms](NOTES-ANDROID.md)
|
||||
* [Notes for Windows platforms](NOTES-WINDOWS.md)
|
||||
* [Notes for the DOS platform with DJGPP](NOTES-DJGPP.md)
|
||||
* [Notes for the OpenVMS platform](NOTES-VMS.md)
|
||||
* [Notes on Perl](NOTES-PERL.md)
|
||||
* [Notes on Valgrind](NOTES-VALGRIND.md)
|
||||
|
||||
Specific notes on upgrading to OpenSSL 3.0 from previous versions can be found
|
||||
in the [migration_guide(7ossl)] manual page.
|
||||
|
||||
Documentation
|
||||
=============
|
||||
|
||||
Manual Pages
|
||||
------------
|
||||
|
||||
The manual pages for the master branch and all current stable releases are
|
||||
available online.
|
||||
|
||||
- [OpenSSL master](https://www.openssl.org/docs/manmaster)
|
||||
- [OpenSSL 3.0](https://www.openssl.org/docs/man3.0)
|
||||
- [OpenSSL 1.1.1](https://www.openssl.org/docs/man1.1.1)
|
||||
|
||||
Wiki
|
||||
----
|
||||
|
||||
There is a Wiki at [wiki.openssl.org] which is currently not very active.
|
||||
It contains a lot of useful information, not all of which is up to date.
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
OpenSSL is licensed under the Apache License 2.0, which means that
|
||||
you are free to get and use it for commercial and non-commercial
|
||||
purposes as long as you fulfill its conditions.
|
||||
|
||||
See the [LICENSE.txt](LICENSE.txt) file for more details.
|
||||
|
||||
Support
|
||||
=======
|
||||
|
||||
There are various ways to get in touch. The correct channel depends on
|
||||
your requirement. see the [SUPPORT](SUPPORT.md) file for more details.
|
||||
|
||||
Contributing
|
||||
============
|
||||
|
||||
If you are interested and willing to contribute to the OpenSSL project,
|
||||
please take a look at the [CONTRIBUTING](CONTRIBUTING.md) file.
|
||||
|
||||
Legalities
|
||||
==========
|
||||
|
||||
A number of nations restrict the use or export of cryptography. If you are
|
||||
potentially subject to such restrictions you should seek legal advice before
|
||||
attempting to develop or distribute cryptographic code.
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
Copyright (c) 1998-2022 The OpenSSL Project
|
||||
|
||||
Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
|
||||
|
||||
All rights reserved.
|
||||
|
||||
<!-- Links -->
|
||||
|
||||
[www.openssl.org]:
|
||||
<https://www.openssl.org>
|
||||
"OpenSSL Homepage"
|
||||
|
||||
[git.openssl.org]:
|
||||
<https://git.openssl.org>
|
||||
"OpenSSL Git Repository"
|
||||
|
||||
[git.openssl.org]:
|
||||
<https://git.openssl.org>
|
||||
"OpenSSL Git Repository"
|
||||
|
||||
[github.com/openssl/openssl]:
|
||||
<https://github.com/openssl/openssl>
|
||||
"OpenSSL GitHub Mirror"
|
||||
|
||||
[wiki.openssl.org]:
|
||||
<https://wiki.openssl.org>
|
||||
"OpenSSL Wiki"
|
||||
|
||||
[migration_guide(7ossl)]:
|
||||
<https://www.openssl.org/docs/man3.0/man7/migration_guide.html>
|
||||
"OpenSSL Migration Guide"
|
||||
|
||||
[RFC 8446]:
|
||||
<https://tools.ietf.org/html/rfc8446>
|
||||
|
||||
<!-- Logos and Badges -->
|
||||
|
||||
[openssl logo]:
|
||||
doc/images/openssl.svg
|
||||
"OpenSSL Logo"
|
||||
|
||||
[github actions ci badge]:
|
||||
<https://github.com/openssl/openssl/workflows/GitHub%20CI/badge.svg>
|
||||
"GitHub Actions CI Status"
|
||||
|
||||
[github actions ci]:
|
||||
<https://github.com/openssl/openssl/actions?query=workflow%3A%22GitHub+CI%22>
|
||||
"GitHub Actions CI"
|
||||
|
||||
[appveyor badge]:
|
||||
<https://ci.appveyor.com/api/projects/status/8e10o7xfrg73v98f/branch/master?svg=true>
|
||||
"AppVeyor Build Status"
|
||||
|
||||
[appveyor jobs]:
|
||||
<https://ci.appveyor.com/project/openssl/openssl/branch/master>
|
||||
"AppVeyor Jobs"
|
||||
@ -0,0 +1,113 @@
|
||||
What This Is
|
||||
============
|
||||
|
||||
This is a fork of [OpenSSL](https://www.openssl.org) to enable QUIC. In addition
|
||||
to the website, the official source distribution is at
|
||||
<https://github.com/openssl/openssl>. The OpenSSL `README` can be found at
|
||||
[README-OpenSSL.md](https://github.com/quictls/openssl/blob/openssl-3.1.0%2Bquic/README-OpenSSL.md)
|
||||
|
||||
This fork adds APIs that can be used by QUIC implementations for connection
|
||||
handshakes. Quoting the IETF Working group
|
||||
[charter](https://datatracker.ietf.org/wg/quic/about/), QUIC is a "UDP-based,
|
||||
stream-multiplexing, encrypted transport protocol." If you don't need QUIC, you
|
||||
should use the official OpenSSL distributions.
|
||||
|
||||
The APIs here are used by Microsoft's
|
||||
[MsQuic](https://github.com/microsoft/msquic) and Google's
|
||||
[Chromium QUIC](https://chromium.googlesource.com/chromium/src/+/master/net/quic/)
|
||||
|
||||
We are not in competition with OpenSSL project. We informed them of
|
||||
our plans to fork the code before we went public. We do not speak for the
|
||||
OpenSSL project, and can only point to a
|
||||
[blog post](https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/) and
|
||||
[openssl-project email](https://github.com/quictls/openssl/discussions/54)
|
||||
that provides their view of QUIC support.
|
||||
|
||||
As stated in their blog post, the OpenSSL team is focused on their 3.0 release
|
||||
(released 2021-09-07), and does not intend to add QUIC functionality to 1.1.x.
|
||||
There is a community need for a QUIC-capable TLS library. This fork is intended
|
||||
as stopgap solution to enable higher level frameworks and runtimes to use QUIC
|
||||
with the proven and reliable TLS functionality from OpenSSL. This fork will be
|
||||
maintained until OpenSSL officially provides reasonable support for QUIC
|
||||
implementations.
|
||||
|
||||
This fork can be considered a supported version of
|
||||
[OpenSSL PR 8797](https://github.com/openssl/openssl/pull/8797).
|
||||
We will endeavor to track OpenSSL releases within a day or so, and there is an
|
||||
item below about how we'll follow their tagging.
|
||||
|
||||
On to the questions and answers.
|
||||
|
||||
What about branches?
|
||||
--------------------
|
||||
|
||||
We don't want to conflict with OpenSSL branch names. Our current plan is to append
|
||||
`+quic`. Release tags are likely to be the QUIC branch with `-releaseX` appended.
|
||||
For example, the OpenSSL tag `openssl-3.0.0` would have a branch named
|
||||
`openssl-3.0.0+quic` and a release tag of `openssl-3.0.0+quic-release1`.
|
||||
|
||||
How are you keeping current with OpenSSL?
|
||||
-----------------------------------------
|
||||
|
||||
(In other words, "What about rebasing?")
|
||||
|
||||
Our plan is to always rebase on top of an upstream release tag. In particular:
|
||||
|
||||
- The changes for QUIC will always be at the tip of the branch -- you will know what
|
||||
is from the original OpenSSL and what is for QUIC.
|
||||
- New versions are quickly created once upstream creates a new tag.
|
||||
- The use of git commands (such as `cherry`) can be used to ensure that all changes
|
||||
have moved forward with minimal or no changes. You will be able to see
|
||||
"QUIC: Add X" on all branches and the commit itself will be nearly identical on
|
||||
all branches, and any changes to that can be easily identified.
|
||||
|
||||
What about library names?
|
||||
-------------------------
|
||||
|
||||
Library names will be the same, but will use a different version number. The version
|
||||
numbers for the current OpenSSL libraries are `1.1` (for the 1.1.0 and 1.1.1 branches)
|
||||
and `3` (for the 3.0 branch). We will be prefixing `81` (ASCII for 'Q') to
|
||||
the version numbers to generate a unique version number.
|
||||
|
||||
- `libcrypto.so.81.3` vs `libcrypto.so.3`
|
||||
- `libcrypto.so.81.1.1` vs `libcrypto.so.1.1`
|
||||
- `libssl.so.81.3` vs `libssl.so.3`
|
||||
- `libssl.so.81.1.1` vs `libssl.so.1.1`
|
||||
|
||||
The SONAME of these libraries are all different, guaranteeing the correct library
|
||||
will be used.
|
||||
|
||||
...and the executable?
|
||||
----------------------
|
||||
|
||||
We currently do not have any plans to change the name, mainly because we
|
||||
haven't made any changes there. If you see a need, please open an issue.
|
||||
|
||||
The `openssl version` command will report that it is `+quic` enabled.
|
||||
|
||||
...and FIPS?
|
||||
------------
|
||||
|
||||
We are not doing anything with FIPS. This is actually good news: you should
|
||||
be able to load the OpenSSL 3.0 FIPS module into an application built against
|
||||
this fork and everything should Just Work™.
|
||||
|
||||
How can I contribute?
|
||||
---------------------
|
||||
|
||||
We want any code here to be acceptable to OpenSSL. This means that all contributors
|
||||
must have signed the appropriate
|
||||
[contributor license agreements](https://www.openssl.org/policies/cla.html). We
|
||||
will not ask for copies of any paperwork, you just need to tell us that you've
|
||||
done so (and we might verify with OpenSSL). We are only interested in making it
|
||||
easier and better for at least the mentioned QUIC implementations to use a variant
|
||||
of OpenSSL. If you have a pull request that changes the TLS protocol, or adds
|
||||
assembly support for a new CPU, or otherwise is not specific to enabling QUIC,
|
||||
please contribute that to OpenSSL. This fork is intended to be a clean extension
|
||||
to OpenSSL, with the deltas being specific to QUIC.
|
||||
|
||||
Who are you?
|
||||
------------
|
||||
|
||||
This is a collaborative effort between [Akamai](https://www.akamai.com) and
|
||||
[Microsoft](https://www.microsoft.com). We welcome anyone to contribute!
|
||||
@ -0,0 +1,118 @@
|
||||
ZLIB DATA COMPRESSION LIBRARY
|
||||
|
||||
zlib 1.2.13 is a general purpose data compression library. All the code is
|
||||
thread safe. The data format used by the zlib library is described by RFCs
|
||||
(Request for Comments) 1950 to 1952 in the files
|
||||
http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
|
||||
rfc1952 (gzip format).
|
||||
|
||||
All functions of the compression library are documented in the file zlib.h
|
||||
(volunteer to write man pages welcome, contact zlib@gzip.org). A usage example
|
||||
of the library is given in the file test/example.c which also tests that
|
||||
the library is working correctly. Another example is given in the file
|
||||
test/minigzip.c. The compression library itself is composed of all source
|
||||
files in the root directory.
|
||||
|
||||
To compile all files and run the test program, follow the instructions given at
|
||||
the top of Makefile.in. In short "./configure; make test", and if that goes
|
||||
well, "make install" should work for most flavors of Unix. For Windows, use
|
||||
one of the special makefiles in win32/ or contrib/vstudio/ . For VMS, use
|
||||
make_vms.com.
|
||||
|
||||
Questions about zlib should be sent to <zlib@gzip.org>, or to Gilles Vollant
|
||||
<info@winimage.com> for the Windows DLL version. The zlib home page is
|
||||
http://zlib.net/ . Before reporting a problem, please check this site to
|
||||
verify that you have the latest version of zlib; otherwise get the latest
|
||||
version and check whether the problem still exists or not.
|
||||
|
||||
PLEASE read the zlib FAQ http://zlib.net/zlib_faq.html before asking for help.
|
||||
|
||||
Mark Nelson <markn@ieee.org> wrote an article about zlib for the Jan. 1997
|
||||
issue of Dr. Dobb's Journal; a copy of the article is available at
|
||||
http://marknelson.us/1997/01/01/zlib-engine/ .
|
||||
|
||||
The changes made in version 1.2.13 are documented in the file ChangeLog.
|
||||
|
||||
Unsupported third party contributions are provided in directory contrib/ .
|
||||
|
||||
zlib is available in Java using the java.util.zip package, documented at
|
||||
http://java.sun.com/developer/technicalArticles/Programming/compression/ .
|
||||
|
||||
A Perl interface to zlib written by Paul Marquess <pmqs@cpan.org> is available
|
||||
at CPAN (Comprehensive Perl Archive Network) sites, including
|
||||
http://search.cpan.org/~pmqs/IO-Compress-Zlib/ .
|
||||
|
||||
A Python interface to zlib written by A.M. Kuchling <amk@amk.ca> is
|
||||
available in Python 1.5 and later versions, see
|
||||
http://docs.python.org/library/zlib.html .
|
||||
|
||||
zlib is built into tcl: http://wiki.tcl.tk/4610 .
|
||||
|
||||
An experimental package to read and write files in .zip format, written on top
|
||||
of zlib by Gilles Vollant <info@winimage.com>, is available in the
|
||||
contrib/minizip directory of zlib.
|
||||
|
||||
|
||||
Notes for some targets:
|
||||
|
||||
- For Windows DLL versions, please see win32/DLL_FAQ.txt
|
||||
|
||||
- For 64-bit Irix, deflate.c must be compiled without any optimization. With
|
||||
-O, one libpng test fails. The test works in 32 bit mode (with the -n32
|
||||
compiler flag). The compiler bug has been reported to SGI.
|
||||
|
||||
- zlib doesn't work with gcc 2.6.3 on a DEC 3000/300LX under OSF/1 2.1 it works
|
||||
when compiled with cc.
|
||||
|
||||
- On Digital Unix 4.0D (formely OSF/1) on AlphaServer, the cc option -std1 is
|
||||
necessary to get gzprintf working correctly. This is done by configure.
|
||||
|
||||
- zlib doesn't work on HP-UX 9.05 with some versions of /bin/cc. It works with
|
||||
other compilers. Use "make test" to check your compiler.
|
||||
|
||||
- gzdopen is not supported on RISCOS or BEOS.
|
||||
|
||||
- For PalmOs, see http://palmzlib.sourceforge.net/
|
||||
|
||||
|
||||
Acknowledgments:
|
||||
|
||||
The deflate format used by zlib was defined by Phil Katz. The deflate and
|
||||
zlib specifications were written by L. Peter Deutsch. Thanks to all the
|
||||
people who reported problems and suggested various improvements in zlib; they
|
||||
are too numerous to cite here.
|
||||
|
||||
Copyright notice:
|
||||
|
||||
(C) 1995-2022 Jean-loup Gailly and Mark Adler
|
||||
|
||||
This software is provided 'as-is', without any express or implied
|
||||
warranty. In no event will the authors be held liable for any damages
|
||||
arising from the use of this software.
|
||||
|
||||
Permission is granted to anyone to use this software for any purpose,
|
||||
including commercial applications, and to alter it and redistribute it
|
||||
freely, subject to the following restrictions:
|
||||
|
||||
1. The origin of this software must not be misrepresented; you must not
|
||||
claim that you wrote the original software. If you use this software
|
||||
in a product, an acknowledgment in the product documentation would be
|
||||
appreciated but is not required.
|
||||
2. Altered source versions must be plainly marked as such, and must not be
|
||||
misrepresented as being the original software.
|
||||
3. This notice may not be removed or altered from any source distribution.
|
||||
|
||||
Jean-loup Gailly Mark Adler
|
||||
jloup@gzip.org madler@alumni.caltech.edu
|
||||
|
||||
If you use the zlib library in a product, we would appreciate *not* receiving
|
||||
lengthy legal documents to sign. The sources are provided for free but without
|
||||
warranty of any kind. The library has been entirely written by Jean-loup
|
||||
Gailly and Mark Adler; it does not include third-party code. We make all
|
||||
contributions to and distributions of this project solely in our personal
|
||||
capacity, and are not conveying any rights to any intellectual property of
|
||||
any third parties.
|
||||
|
||||
If you redistribute modified sources, we would appreciate that you include in
|
||||
the file ChangeLog history information documenting your changes. Please read
|
||||
the FAQ for more information on the distribution of modified source versions.
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,800 @@
|
||||
v1.5.5 (Apr 2023)
|
||||
fix: fix rare corruption bug affecting the high compression mode, reported by @danlark1 (#3517, @terrelln)
|
||||
perf: improve mid-level compression speed (#3529, #3533, #3543, @yoniko and #3552, @terrelln)
|
||||
lib: deprecated bufferless block-level API (#3534) by @terrelln
|
||||
cli: mmap large dictionaries to save memory, by @daniellerozenblit
|
||||
cli: improve speed of --patch-from mode (~+50%) (#3545) by @daniellerozenblit
|
||||
cli: improve i/o speed (~+10%) when processing lots of small files (#3479) by @felixhandte
|
||||
cli: zstd no longer crashes when requested to write into write-protected directory (#3541) by @felixhandte
|
||||
cli: fix decompression into block device using -o, reported by @georgmu (#3583)
|
||||
build: fix zstd CLI compiled with lzma support but not zlib support (#3494) by @Hello71
|
||||
build: fix cmake does no longer require 3.18 as minimum version (#3510) by @kou
|
||||
build: fix MSVC+ClangCL linking issue (#3569) by @tru
|
||||
build: fix zstd-dll, version of zstd CLI that links to the dynamic library (#3496) by @yoniko
|
||||
build: fix MSVC warnings (#3495) by @embg
|
||||
doc: updated zstd specification to clarify corner cases, by @Cyan4973
|
||||
doc: document how to create fat binaries for macos (#3568) by @rickmark
|
||||
misc: improve seekable format ingestion speed (~+100%) for very small chunk sizes (#3544) by @Cyan4973
|
||||
misc: tests/fullbench can benchmark multiple files (#3516) by @dloidolt
|
||||
|
||||
v1.5.4 (Feb 2023)
|
||||
perf: +20% faster huffman decompression for targets that can't compile x64 assembly (#3449, @terrelln)
|
||||
perf: up to +10% faster streaming compression at levels 1-2 (#3114, @embg)
|
||||
perf: +4-13% for levels 5-12 by optimizing function generation (#3295, @terrelln)
|
||||
pref: +3-11% compression speed for `arm` target (#3199, #3164, #3145, #3141, #3138, @JunHe77 and #3139, #3160, @danlark1)
|
||||
perf: +5-30% faster dictionary compression at levels 1-4 (#3086, #3114, #3152, @embg)
|
||||
perf: +10-20% cold dict compression speed by prefetching CDict tables (#3177, @embg)
|
||||
perf: +1% faster compression by removing a branch in ZSTD_fast_noDict (#3129, @felixhandte)
|
||||
perf: Small compression ratio improvements in high compression mode (#2983, #3391, @Cyan4973 and #3285, #3302, @daniellerozenblit)
|
||||
perf: small speed improvement by better detecting `STATIC_BMI2` for `clang` (#3080, @TocarIP)
|
||||
perf: Improved streaming performance when `ZSTD_c_stableInBuffer` is set (#2974, @Cyan4973)
|
||||
cli: Asynchronous I/O for improved cli speed (#2975, #2985, #3021, #3022, @yoniko)
|
||||
cli: Change `zstdless` behavior to align with `zless` (#2909, @binhdvo)
|
||||
cli: Keep original file if `-c` or `--stdout` is given (#3052, @dirkmueller)
|
||||
cli: Keep original files when result is concatenated into a single output with `-o` (#3450, @Cyan4973)
|
||||
cli: Preserve Permissions and Ownership of regular files (#3432, @felixhandte)
|
||||
cli: Print zlib/lz4/lzma library versions with `-vv` (#3030, @terrelln)
|
||||
cli: Print checksum value for single frame files with `-lv` (#3332, @Cyan4973)
|
||||
cli: Print `dictID` when present with `-lv` (#3184, @htnhan)
|
||||
cli: when `stderr` is *not* the console, disable status updates, but preserve final summary (#3458, @Cyan4973)
|
||||
cli: support `--best` and `--no-name` in `gzip` compatibility mode (#3059, @dirkmueller)
|
||||
cli: support for `posix` high resolution timer `clock_gettime()`, for improved benchmark accuracy (#3423, @Cyan4973)
|
||||
cli: improved help/usage (`-h`, `-H`) formatting (#3094, @dirkmueller and #3385, @jonpalmisc)
|
||||
cli: Fix better handling of bogus numeric values (#3268, @ctkhanhly)
|
||||
cli: Fix input consists of multiple files _and_ `stdin` (#3222, @yoniko)
|
||||
cli: Fix tiny files passthrough (#3215, @cgbur)
|
||||
cli: Fix for `-r` on empty directory (#3027, @brailovich)
|
||||
cli: Fix empty string as argument for `--output-dir-*` (#3220, @embg)
|
||||
cli: Fix decompression memory usage reported by `-vv --long` (#3042, @u1f35c, and #3232, @zengyijing)
|
||||
cli: Fix infinite loop when empty input is passed to trainer (#3081, @terrelln)
|
||||
cli: Fix `--adapt` doesn't work when `--no-progress` is also set (#3354, @terrelln)
|
||||
api: Support for Block-Level Sequence Producer (#3333, @embg)
|
||||
api: Support for in-place decompression (#3432, @terrelln)
|
||||
api: New `ZSTD_CCtx_setCParams()` function, set all parameters defined in a `ZSTD_compressionParameters` structure (#3403, @Cyan4973)
|
||||
api: Streaming decompression detects incorrect header ID sooner (#3175, @Cyan4973)
|
||||
api: Window size resizing optimization for edge case (#3345, @daniellerozenblit)
|
||||
api: More accurate error codes for busy-loop scenarios (#3413, #3455, @Cyan4973)
|
||||
api: Fix limit overflow in `compressBound` and `decompressBound` (#3362, #3373, Cyan4973) reported by @nigeltao
|
||||
api: Deprecate several advanced experimental functions: streaming (#3408, @embg), copy (#3196, @mileshu)
|
||||
bug: Fix corruption that rarely occurs in 32-bit mode with wlog=25 (#3361, @terrelln)
|
||||
bug: Fix for block-splitter (#3033, @Cyan4973)
|
||||
bug: Fixes for Sequence Compression API (#3023, #3040, @Cyan4973)
|
||||
bug: Fix leaking thread handles on Windows (#3147, @animalize)
|
||||
bug: Fix timing issues with cmake/meson builds (#3166, #3167, #3170, @Cyan4973)
|
||||
build: Allow user to select legacy level for cmake (#3050, @shadchin)
|
||||
build: Enable legacy support by default in cmake (#3079, @niamster)
|
||||
build: Meson build script improvements (#3039, #3120, #3122, #3327, #3357, @eli-schwartz and #3276, @neheb)
|
||||
build: Add aarch64 to supported architectures for zstd_trace (#3054, @ooosssososos)
|
||||
build: support AIX architecture (#3219, @qiongsiwu)
|
||||
build: Fix `ZSTD_LIB_MINIFY` build macro, which now reduces static library size by half (#3366, @terrelln)
|
||||
build: Fix Windows issues with Multithreading translation layer (#3364, #3380, @yoniko) and ARM64 target (#3320, @cwoffenden)
|
||||
build: Fix `cmake` script (#3382, #3392, @terrelln and #3252 @Tachi107 and #3167 @Cyan4973)
|
||||
doc: Updated man page, providing more details for `--train` mode (#3112, @Cyan4973)
|
||||
doc: Add decompressor errata document (#3092, @terrelln)
|
||||
misc: Enable Intel CET (#2992, #2994, @hjl-tools)
|
||||
misc: Fix `contrib/` seekable format (#3058, @yhoogstrate and #3346, @daniellerozenblit)
|
||||
misc: Improve speed of the one-file library generator (#3241, @wahern and #3005, @cwoffenden)
|
||||
|
||||
v1.5.3 (dev version, unpublished)
|
||||
|
||||
v1.5.2 (Jan, 2022)
|
||||
perf: Regain Minimal memset()-ing During Reuse of Compression Contexts (@Cyan4973, #2969)
|
||||
build: Build Zstd with `noexecstack` on All Architectures (@felixhandte, #2964)
|
||||
doc: Clarify Licensing (@terrelln, #2981)
|
||||
|
||||
v1.5.1 (Dec, 2021)
|
||||
perf: rebalanced compression levels, to better match the intended speed/level curve, by @senhuang42
|
||||
perf: faster huffman decoder, using x64 assembly, by @terrelln
|
||||
perf: slightly faster high speed modes (strategies fast & dfast), by @felixhandte
|
||||
perf: improved binary size and faster compilation times, by @terrelln
|
||||
perf: new row64 mode, used notably in level 12, by @senhuang42
|
||||
perf: faster mid-level compression speed in presence of highly repetitive patterns, by @senhuang42
|
||||
perf: minor compression ratio improvements for small data at high levels, by @cyan4973
|
||||
perf: reduced stack usage (mostly useful for Linux Kernel), by @terrelln
|
||||
perf: faster compression speed on incompressible data, by @bindhvo
|
||||
perf: on-demand reduced ZSTD_DCtx state size, using build macro ZSTD_DECODER_INTERNAL_BUFFER, at a small cost of performance, by @bindhvo
|
||||
build: allows hiding static symbols in the dynamic library, using build macro, by @skitt
|
||||
build: support for m68k (Motorola 68000's), by @cyan4973
|
||||
build: improved AIX support, by @Helflym
|
||||
build: improved meson unofficial build, by @eli-schwartz
|
||||
cli : custom memory limit when training dictionary (#2925), by @embg
|
||||
cli : report advanced parameters information when compressing in very verbose mode (``-vv`), by @Svetlitski-FB
|
||||
|
||||
v1.5.0 (May 11, 2021)
|
||||
api: Various functions promoted from experimental to stable API: (#2579-2581, @senhuang42)
|
||||
`ZSTD_defaultCLevel()`
|
||||
`ZSTD_getDictID_fromCDict()`
|
||||
api: Several experimental functions have been deprecated and will emit a compiler warning (#2582, @senhuang42)
|
||||
`ZSTD_compress_advanced()`
|
||||
`ZSTD_compress_usingCDict_advanced()`
|
||||
`ZSTD_compressBegin_advanced()`
|
||||
`ZSTD_compressBegin_usingCDict_advanced()`
|
||||
`ZSTD_initCStream_srcSize()`
|
||||
`ZSTD_initCStream_usingDict()`
|
||||
`ZSTD_initCStream_usingCDict()`
|
||||
`ZSTD_initCStream_advanced()`
|
||||
`ZSTD_initCStream_usingCDict_advanced()`
|
||||
`ZSTD_resetCStream()`
|
||||
api: ZSTDMT_NBWORKERS_MAX reduced to 64 for 32-bit environments (@Cyan4973)
|
||||
perf: Significant speed improvements for middle compression levels (#2494, @senhuang42 @terrelln)
|
||||
perf: Block splitter to improve compression ratio, enabled by default for high compression levels (#2447, @senhuang42)
|
||||
perf: Decompression loop refactor, speed improvements on `clang` and for `--long` modes (#2614 #2630, @Cyan4973)
|
||||
perf: Reduced stack usage during compression and decompression entropy stage (#2522 #2524, @terrelln)
|
||||
bug: Improve setting permissions of created files (#2525, @felixhandte)
|
||||
bug: Fix large dictionary non-determinism (#2607, @terrelln)
|
||||
bug: Fix non-determinism test failures on Linux i686 (#2606, @terrelln)
|
||||
bug: Fix various dedicated dictionary search bugs (#2540 #2586, @senhuang42 @felixhandte)
|
||||
bug: Ensure `ZSTD_estimateCCtxSize*() `monotonically increases with compression level (#2538, @senhuang42)
|
||||
bug: Fix --patch-from mode parameter bound bug with small files (#2637, @occivink)
|
||||
bug: Fix UBSAN error in decompression (#2625, @terrelln)
|
||||
bug: Fix superblock compression divide by zero bug (#2592, @senhuang42)
|
||||
bug: Make the number of physical CPU cores detection more robust (#2517, @PaulBone)
|
||||
doc: Improve `zdict.h` dictionary training API documentation (#2622, @terrelln)
|
||||
doc: Note that public `ZSTD_free*()` functions accept NULL pointers (#2521, @animalize)
|
||||
doc: Add style guide docs for open source contributors (#2626, @Cyan4973)
|
||||
tests: Better regression test coverage for different dictionary modes (#2559, @senhuang42)
|
||||
tests: Better test coverage of index reduction (#2603, @terrelln)
|
||||
tests: OSS-Fuzz coverage for seekable format (#2617, @senhuang42)
|
||||
tests: Test coverage for ZSTD threadpool API (#2604, @senhuang42)
|
||||
build: Dynamic library built multithreaded by default (#2584, @senhuang42)
|
||||
build: Move `zstd_errors.h` and `zdict.h` to `lib/` root (#2597, @terrelln)
|
||||
build: Allow `ZSTDMT_JOBSIZE_MIN` to be configured at compile-time, reduce default to 512KB (#2611, @Cyan4973)
|
||||
build: Single file library build script moved to `build/` directory (#2618, @felixhandte)
|
||||
build: `ZBUFF_*()` is no longer built by default (#2583, @senhuang42)
|
||||
build: Fixed Meson build (#2548, @SupervisedThinking @kloczek)
|
||||
build: Fix excessive compiler warnings with clang-cl and CMake (#2600, @nickhutchinson)
|
||||
build: Detect presence of `md5` on Darwin (#2609, @felixhandte)
|
||||
build: Avoid SIGBUS on armv6 (#2633, @bmwiedmann)
|
||||
cli: `--progress` flag added to always display progress bar (#2595, @senhuang42)
|
||||
cli: Allow reading from block devices with `--force` (#2613, @felixhandte)
|
||||
cli: Fix CLI filesize display bug (#2550, @Cyan4973)
|
||||
cli: Fix windows CLI `--filelist` end-of-line bug (#2620, @Cyan4973)
|
||||
contrib: Various fixes for linux kernel patch (#2539, @terrelln)
|
||||
contrib: Seekable format - Decompression hanging edge case fix (#2516, @senhuang42)
|
||||
contrib: Seekable format - New seek table-only API (#2113 #2518, @mdittmer @Cyan4973)
|
||||
contrib: Seekable format - Fix seek table descriptor check when loading (#2534, @foxeng)
|
||||
contrib: Seekable format - Decompression fix for large offsets, (#2594, @azat)
|
||||
misc: Automatically published release tarballs available on Github (#2535, @felixhandte)
|
||||
|
||||
v1.4.9 (Mar 1, 2021)
|
||||
bug: Use `umask()` to Constrain Created File Permissions (#2495, @felixhandte)
|
||||
bug: Make Simple Single-Pass Functions Ignore Advanced Parameters (#2498, @terrelln)
|
||||
api: Add (De)Compression Tracing Functionality (#2482, @terrelln)
|
||||
api: Support References to Multiple DDicts (#2446, @senhuang42)
|
||||
api: Add Function to Generate Skippable Frame (#2439, @senhuang42)
|
||||
perf: New Algorithms for the Long Distance Matcher (#2483, @mpu)
|
||||
perf: Performance Improvements for Long Distance Matcher (#2464, @mpu)
|
||||
perf: Don't Shrink Window Log when Streaming with a Dictionary (#2451, @terrelln)
|
||||
cli: Fix `--output-dir-mirror`'s Rejection of `..`-Containing Paths (#2512, @felixhandte)
|
||||
cli: Allow Input From Console When `-f`/`--force` is Passed (#2466, @felixhandte)
|
||||
cli: Improve Help Message (#2500, @senhuang42)
|
||||
tests: Remove Flaky Tests (#2455, #2486, #2445, @Cyan4973)
|
||||
tests: Correctly Invoke md5 Utility on NetBSD (#2492, @niacat)
|
||||
tests: Avoid Using `stat -c` on NetBSD (#2513, @felixhandte)
|
||||
build: Zstd CLI Can Now be Linked to Dynamic `libzstd` (#2457, #2454 @Cyan4973)
|
||||
build: Hide and Avoid Using Static-Only Symbols (#2501, #2504, @skitt)
|
||||
build: CMake: Enable Only C for lib/ and programs/ Projects (#2498, @concatime)
|
||||
build: CMake: Use `configure_file()` to Create the `.pc` File (#2462, @lazka)
|
||||
build: Fix Fuzzer Compiler Detection & Update UBSAN Flags (#2503, @terrelln)
|
||||
build: Add Guards for `_LARGEFILE_SOURCE` and `_LARGEFILE64_SOURCE` (#2444, @indygreg)
|
||||
build: Improve `zlibwrapper` Makefile (#2437, @Cyan4973)
|
||||
contrib: Add `recover_directory` Program (#2473, @terrelln)
|
||||
doc: Change License Year to 2021 (#2452 & #2465, @terrelln & @senhuang42)
|
||||
doc: Fix Typos (#2459, @ThomasWaldmann)
|
||||
|
||||
v1.4.8 (Dec 18, 2020)
|
||||
hotfix: wrong alignment of an internal buffer
|
||||
|
||||
v1.4.7 (Dec 16, 2020)
|
||||
perf: stronger --long mode at high compression levels, by @senhuang42
|
||||
perf: stronger --patch-from at high compression levels, thanks to --long improvements
|
||||
perf: faster dictionary compression at medium compression levels, by @felixhandte
|
||||
perf: small speed & memory usage improvements for ZSTD_compress2(), by @terrelln
|
||||
perf: improved fast compression speeds with Visual Studio, by @animalize
|
||||
cli : Set nb of threads with environment variable ZSTD_NBTHREADS, by @senhuang42
|
||||
cli : accept decompressing files with *.zstd suffix
|
||||
cli : provide a condensed summary by default when processing multiple files
|
||||
cli : fix : stdin input no longer confused as user prompt
|
||||
cli : improve accuracy of several error messages
|
||||
api : new sequence ingestion API, by @senhuang42
|
||||
api : shared thread pool: control total nb of threads used by multiple compression jobs, by @marxin
|
||||
api : new ZSTD_getDictID_fromCDict(), by @LuAPi
|
||||
api : zlibWrapper only uses public API, and is compatible with dynamic library, by @terrelln
|
||||
api : fix : multithreaded compression has predictable output even in special cases (see #2327) (issue not accessible from cli)
|
||||
api : fix : dictionary compression correctly respects dictionary compression level (see #2303) (issue not accessible from cli)
|
||||
build: fix cmake script when using path with spaces, by @terrelln
|
||||
build: improved compile-time detection of aarch64/neon platforms, by @bsdimp
|
||||
build: Fix building on AIX 5.1, by @likema
|
||||
build: compile paramgrill with cmake on Windows, requested by @mirh
|
||||
doc : clarify repcode updates in format specification, by @felixhandte
|
||||
|
||||
v1.4.6
|
||||
fix : Always return dstSize_tooSmall when that is the case
|
||||
fix : Fix ZSTD_initCStream_advanced() with static allocation and no dictionary
|
||||
perf: Improve small block decompression speed by 20%+, by @terrelln
|
||||
perf: Reduce compression stack usage by 1 KB, by @terrelln
|
||||
perf: Improve decompression speed by improving ZSTD_wildcopy, by @helloguo (#2252, #2256)
|
||||
perf: Improve histogram construction, by @cyan4973 (#2253)
|
||||
cli : Add --output-dir-mirror option, by @xxie24 (#2219)
|
||||
cli : Warn when (de)compressing multiple files into a single output, by @senhuang42 (#2279)
|
||||
cli : Improved progress bar and status summary when (de)compressing multiple files, by @senhuang42 (#2283)
|
||||
cli : Call stat less often, by @felixhandte (#2262)
|
||||
cli : Allow --patch-from XXX and --filelist XXX in addition to --patch-from=XXX and --filelist=XXX, by @cyan4973 (#2250)
|
||||
cli : Allow --patch-from to compress stdin with --stream-size, by @bimbashrestha (#2206)
|
||||
api : Do not install zbuff.h, since it has long been deprecated, by @cyan4973 (#2166).
|
||||
api : Fix ZSTD_CCtx_setParameter() with ZSTD_c_compressionLevel to make 0 mean default level, by @i-do-cpp (#2291)
|
||||
api : Rename ZSTDMT_NBTHREADS_MAX to ZSTDMT_NBWORKERS_MAX, by @marxin (#2228).
|
||||
build: Install pkg-config file with CMake and MinGW, by @tonytheodore (#2183)
|
||||
build: Install DLL with CMake on Windows, by @BioDataAnalysis (#2221)
|
||||
build: Fix DLL install location with CMake, by @xantares and @bimbashrestha (#2186)
|
||||
build: Add ZSTD_NO_UNUSED_FUNCTIONS macro to hide unused functions
|
||||
build: Add ZSTD_NO_INTRINSICS macro to avoid explicit intrinsics
|
||||
build: Add STATIC_BMI2 macro for compile time detection of BMI2 on MSVC, by @Niadb (#2258)
|
||||
build: Fix -Wcomma warnings, by @cwoffenden
|
||||
build: Remove distutils requirement for meson build, by @neheb (#2197)
|
||||
build: Fix cli compilation with uclibc
|
||||
build: Fix cli compilation without st_mtime, by @ffontaine (#2246)
|
||||
build: Fix shadowing warnings in library
|
||||
build: Fix single file library compilation with Enscripten, by @yoshihitoh (#2227)
|
||||
misc: Improve single file library and include dictBuilder, by @cwoffenden
|
||||
misc: Allow compression dictionaries with missing symbols
|
||||
misc: Add freestanding translation script in contrib/freestanding_lib
|
||||
misc: Collect all of zstd's libc dependencies into zstd_deps.h
|
||||
doc : Add ZSTD_versionString() to manual, by @animalize
|
||||
doc : Fix documentation for ZSTD_CCtxParams_setParameter(), by @felixhandte (#2270)
|
||||
|
||||
v1.4.5 (May 22, 2020)
|
||||
fix : Compression ratio regression on huge files (> 3 GB) using high levels (--ultra) and multithreading, by @terrelln
|
||||
perf: Improved decompression speed: x64 : +10% (clang) / +5% (gcc); ARM : from +15% to +50%, depending on SoC, by @terrelln
|
||||
perf: Automatically downsizes ZSTD_DCtx when too large for too long (#2069, by @bimbashreshta)
|
||||
perf: Improved fast compression speed on aarch64 (#2040, ~+3%, by @caoyzh)
|
||||
perf: Small level 1 compression speed gains (depending on compiler)
|
||||
cli : New --patch-from command, create and apply patches from files, by @bimbashreshta
|
||||
cli : New --filelist= : Provide a list of files to operate upon from a file
|
||||
cli : -b -d command can now benchmark decompression on multiple files
|
||||
cli : New --no-content-size command
|
||||
cli : New --show-default-cparams information command
|
||||
api : ZDICT_finalizeDictionary() is promoted to stable (#2111)
|
||||
api : new experimental parameter ZSTD_d_stableOutBuffer (#2094)
|
||||
build: Generate a single-file libzstd library (#2065, by @cwoffenden)
|
||||
build: Relative includes no longer require -I compiler flags for zstd lib subdirs (#2103, by @felixhandte)
|
||||
build: zstd now compiles cleanly under -pedantic (#2099)
|
||||
build: zstd now compiles with make-4.3
|
||||
build: Support mingw cross-compilation from Linux, by @Ericson2314
|
||||
build: Meson multi-thread build fix on windows
|
||||
build: Some misc icc fixes backed by new ci test on travis
|
||||
misc: bitflip analyzer tool, by @felixhandte
|
||||
misc: Extend largeNbDicts benchmark to compression
|
||||
misc: Edit-distance match finder in contrib/
|
||||
doc : Improved beginner CONTRIBUTING.md docs
|
||||
doc : New issue templates for zstd
|
||||
|
||||
v1.4.4 (Nov 6, 2019)
|
||||
perf: Improved decompression speed, by > 10%, by @terrelln
|
||||
perf: Better compression speed when re-using a context, by @felixhandte
|
||||
perf: Fix compression ratio when compressing large files with small dictionary, by @senhuang42
|
||||
perf: zstd reference encoder can generate RLE blocks, by @bimbashrestha
|
||||
perf: minor generic speed optimization, by @davidbolvansky
|
||||
api: new ability to extract sequences from the parser for analysis, by @bimbashrestha
|
||||
api: fixed decoding of magic-less frames, by @terrelln
|
||||
api: fixed ZSTD_initCStream_advanced() performance with fast modes, reported by @QrczakMK
|
||||
cli: Named pipes support, by @bimbashrestha
|
||||
cli: short tar's extension support, by @stokito
|
||||
cli: command --output-dir-flat= , generates target files into requested directory, by @senhuang42
|
||||
cli: commands --stream-size=# and --size-hint=#, by @nmagerko
|
||||
cli: command --exclude-compressed, by @shashank0791
|
||||
cli: faster `-t` test mode
|
||||
cli: improved some error messages, by @vangyzen
|
||||
cli: fix command `-D dictionary` on Windows, reported by @artyompetrov
|
||||
cli: fix rare deadlock condition within dictionary builder, by @terrelln
|
||||
build: single-file decoder with emscripten compilation script, by @cwoffenden
|
||||
build: fixed zlibWrapper compilation on Visual Studio, reported by @bluenlive
|
||||
build: fixed deprecation warning for certain gcc version, reported by @jasonma163
|
||||
build: fix compilation on old gcc versions, by @cemeyer
|
||||
build: improved installation directories for cmake script, by Dmitri Shubin
|
||||
pack: modified pkgconfig, for better integration into openwrt, requested by @neheb
|
||||
misc: Improved documentation : ZSTD_CLEVEL, DYNAMIC_BMI2, ZSTD_CDict, function deprecation, zstd format
|
||||
misc: fixed educational decoder : accept larger literals section, and removed UNALIGNED() macro
|
||||
|
||||
v1.4.3 (Aug 20, 2019)
|
||||
bug: Fix Dictionary Compression Ratio Regression by @cyan4973 (#1709)
|
||||
bug: Fix Buffer Overflow in legacy v0.3 decompression by @felixhandte (#1722)
|
||||
build: Add support for IAR C/C++ Compiler for Arm by @joseph0918 (#1705)
|
||||
|
||||
v1.4.2 (Jul 26, 2019)
|
||||
bug: Fix bug in zstd-0.5 decoder by @terrelln (#1696)
|
||||
bug: Fix seekable decompression in-memory API by @iburinoc (#1695)
|
||||
misc: Validate blocks are smaller than size limit by @vivekmg (#1685)
|
||||
misc: Restructure source files by @ephiepark (#1679)
|
||||
|
||||
v1.4.1 (Jul 20, 2019)
|
||||
bug: Fix data corruption in niche use cases by @terrelln (#1659)
|
||||
bug: Fuzz legacy modes, fix uncovered bugs by @terrelln (#1593, #1594, #1595)
|
||||
bug: Fix out of bounds read by @terrelln (#1590)
|
||||
perf: Improve decode speed by ~7% @mgrice (#1668)
|
||||
perf: Slightly improved compression ratio of level 3 and 4 (ZSTD_dfast) by @cyan4973 (#1681)
|
||||
perf: Slightly faster compression speed when re-using a context by @cyan4973 (#1658)
|
||||
perf: Improve compression ratio for small windowLog by @cyan4973 (#1624)
|
||||
perf: Faster compression speed in high compression mode for repetitive data by @terrelln (#1635)
|
||||
api: Add parameter to generate smaller dictionaries by @tyler-tran (#1656)
|
||||
cli: Recognize symlinks when built in C99 mode by @felixhandte (#1640)
|
||||
cli: Expose cpu load indicator for each file on -vv mode by @ephiepark (#1631)
|
||||
cli: Restrict read permissions on destination files by @chungy (#1644)
|
||||
cli: zstdgrep: handle -f flag by @felixhandte (#1618)
|
||||
cli: zstdcat: follow symlinks by @vejnar (#1604)
|
||||
doc: Remove extra size limit on compressed blocks by @felixhandte (#1689)
|
||||
doc: Fix typo by @yk-tanigawa (#1633)
|
||||
doc: Improve documentation on streaming buffer sizes by @cyan4973 (#1629)
|
||||
build: CMake: support building with LZ4 @leeyoung624 (#1626)
|
||||
build: CMake: install zstdless and zstdgrep by @leeyoung624 (#1647)
|
||||
build: CMake: respect existing uninstall target by @j301scott (#1619)
|
||||
build: Make: skip multithread tests when built without support by @michaelforney (#1620)
|
||||
build: Make: Fix examples/ test target by @sjnam (#1603)
|
||||
build: Meson: rename options out of deprecated namespace by @lzutao (#1665)
|
||||
build: Meson: fix build by @lzutao (#1602)
|
||||
build: Visual Studio: don't export symbols in static lib by @scharan (#1650)
|
||||
build: Visual Studio: fix linking by @absotively (#1639)
|
||||
build: Fix MinGW-W64 build by @myzhang1029 (#1600)
|
||||
misc: Expand decodecorpus coverage by @ephiepark (#1664)
|
||||
|
||||
v1.4.0 (Apr 17, 2019)
|
||||
perf: Improve level 1 compression speed in most scenarios by 6% by @gbtucker and @terrelln
|
||||
api: Move the advanced API, including all functions in the staging section, to the stable section
|
||||
api: Make ZSTD_e_flush and ZSTD_e_end block for maximum forward progress
|
||||
api: Rename ZSTD_CCtxParam_getParameter to ZSTD_CCtxParams_getParameter
|
||||
api: Rename ZSTD_CCtxParam_setParameter to ZSTD_CCtxParams_setParameter
|
||||
api: Don't export ZSTDMT functions from the shared library by default
|
||||
api: Require ZSTD_MULTITHREAD to be defined to use ZSTDMT
|
||||
api: Add ZSTD_decompressBound() to provide an upper bound on decompressed size by @shakeelrao
|
||||
api: Fix ZSTD_decompressDCtx() corner cases with a dictionary
|
||||
api: Move ZSTD_getDictID_*() functions to the stable section
|
||||
api: Add ZSTD_c_literalCompressionMode flag to enable or disable literal compression by @terrelln
|
||||
api: Allow compression parameters to be set when a dictionary is used
|
||||
api: Allow setting parameters before or after ZSTD_CCtx_loadDictionary() is called
|
||||
api: Fix ZSTD_estimateCStreamSize_usingCCtxParams()
|
||||
api: Setting ZSTD_d_maxWindowLog to 0 means use the default
|
||||
cli: Ensure that a dictionary is not used to compress itself by @shakeelrao
|
||||
cli: Add --[no-]compress-literals flag to enable or disable literal compression
|
||||
doc: Update the examples to use the advanced API
|
||||
doc: Explain how to transition from old streaming functions to the advanced API in the header
|
||||
build: Improve the Windows release packages
|
||||
build: Improve CMake build by @hjmjohnson
|
||||
build: Build fixes for FreeBSD by @lwhsu
|
||||
build: Remove redundant warnings by @thatsafunnyname
|
||||
build: Fix tests on OpenBSD by @bket
|
||||
build: Extend fuzzer build system to work with the new clang engine
|
||||
build: CMake now creates the libzstd.so.1 symlink
|
||||
build: Improve Menson build by @lzutao
|
||||
misc: Fix symbolic link detection on FreeBSD
|
||||
misc: Use physical core count for -T0 on FreeBSD by @cemeyer
|
||||
misc: Fix zstd --list on truncated files by @kostmo
|
||||
misc: Improve logging in debug mode by @felixhandte
|
||||
misc: Add CirrusCI tests by @lwhsu
|
||||
misc: Optimize dictionary memory usage in corner cases
|
||||
misc: Improve the dictionary builder on small or homogeneous data
|
||||
misc: Fix spelling across the repo by @jsoref
|
||||
|
||||
v1.3.8 (Dec 28, 2018)
|
||||
perf: better decompression speed on large files (+7%) and cold dictionaries (+15%)
|
||||
perf: slightly better compression ratio at high compression modes
|
||||
api : finalized advanced API, last stage before "stable" status
|
||||
api : new --rsyncable mode, by @terrelln
|
||||
api : support decompression of empty frames into NULL (used to be an error) (#1385)
|
||||
build: new set of macros to build a minimal size decoder, by @felixhandte
|
||||
build: fix compilation on MIPS32, reported by @clbr (#1441)
|
||||
build: fix compilation with multiple -arch flags, by @ryandesign
|
||||
build: highly upgraded meson build, by @lzutao
|
||||
build: improved buck support, by @obelisk
|
||||
build: fix cmake script : can create debug build, by @pitrou
|
||||
build: Makefile : grep works on both colored consoles and systems without color support
|
||||
build: fixed zstd-pgo, by @bmwiedemann
|
||||
cli : support ZSTD_CLEVEL environment variable, by @yijinfb (#1423)
|
||||
cli : --no-progress flag, preserving final summary (#1371), by @terrelln
|
||||
cli : ensure destination file is not source file (#1422)
|
||||
cli : clearer error messages, especially when input file not present
|
||||
doc : clarified zstd_compression_format.md, by @ulikunitz
|
||||
misc: fixed zstdgrep, returns 1 on failure, by @lzutao
|
||||
misc: NEWS renamed as CHANGELOG, in accordance with fboss
|
||||
|
||||
v1.3.7 (Oct 20, 2018)
|
||||
perf: slightly better decompression speed on clang (depending on hardware target)
|
||||
fix : performance of dictionary compression for small input < 4 KB at levels 9 and 10
|
||||
build: no longer build backtrace by default in release mode; restrict further automatic mode
|
||||
build: control backtrace support through build macro BACKTRACE
|
||||
misc: added man pages for zstdless and zstdgrep, by @samrussell
|
||||
|
||||
v1.3.6 (Oct 6, 2018)
|
||||
perf: much faster dictionary builder, by @jenniferliu
|
||||
perf: faster dictionary compression on small data when using multiple contexts, by @felixhandte
|
||||
perf: faster dictionary decompression when using a very large number of dictionaries simultaneously
|
||||
cli : fix : does no longer overwrite destination when source does not exist (#1082)
|
||||
cli : new command --adapt, for automatic compression level adaptation
|
||||
api : fix : block api can be streamed with > 4 GB, reported by @catid
|
||||
api : reduced ZSTD_DDict size by 2 KB
|
||||
api : minimum negative compression level is defined, and can be queried using ZSTD_minCLevel().
|
||||
build: support Haiku target, by @korli
|
||||
build: Read Legacy format is limited to v0.5+ by default. Can be changed at compile time with macro ZSTD_LEGACY_SUPPORT.
|
||||
doc : zstd_compression_format.md updated to match wording in IETF RFC 8478
|
||||
misc: tests/paramgrill, a parameter optimizer, by @GeorgeLu97
|
||||
|
||||
v1.3.5 (Jun 29, 2018)
|
||||
perf: much faster dictionary compression, by @felixhandte
|
||||
perf: small quality improvement for dictionary generation, by @terrelln
|
||||
perf: slightly improved high compression levels (notably level 19)
|
||||
mem : automatic memory release for long duration contexts
|
||||
cli : fix : overlapLog can be manually set
|
||||
cli : fix : decoding invalid lz4 frames
|
||||
api : fix : performance degradation for dictionary compression when using advanced API, by @terrelln
|
||||
api : change : clarify ZSTD_CCtx_reset() vs ZSTD_CCtx_resetParameters(), by @terrelln
|
||||
build: select custom libzstd scope through control macros, by @GeorgeLu97
|
||||
build: OpenBSD patch, by @bket
|
||||
build: make and make all are compatible with -j
|
||||
doc : clarify zstd_compression_format.md, updated for IETF RFC process
|
||||
misc: pzstd compatible with reproducible compilation, by @lamby
|
||||
|
||||
v1.3.4 (Mar 27, 2018)
|
||||
perf: faster speed (especially decoding speed) on recent cpus (haswell+)
|
||||
perf: much better performance associating --long with multi-threading, by @terrelln
|
||||
perf: better compression at levels 13-15
|
||||
cli : asynchronous compression by default, for faster experience (use --single-thread for former behavior)
|
||||
cli : smoother status report in multi-threading mode
|
||||
cli : added command --fast=#, for faster compression modes
|
||||
cli : fix crash when not overwriting existing files, by Pádraig Brady (@pixelb)
|
||||
api : `nbThreads` becomes `nbWorkers` : 1 triggers asynchronous mode
|
||||
api : compression levels can be negative, for even more speed
|
||||
api : ZSTD_getFrameProgression() : get precise progress status of ZSTDMT anytime
|
||||
api : ZSTDMT can accept new compression parameters during compression
|
||||
api : implemented all advanced dictionary decompression prototypes
|
||||
build: improved meson recipe, by Shawn Landden (@shawnl)
|
||||
build: VS2017 scripts, by @HaydnTrigg
|
||||
misc: all /contrib projects fixed
|
||||
misc: added /contrib/docker script by @gyscos
|
||||
|
||||
v1.3.3 (Dec 21, 2017)
|
||||
perf: faster zstd_opt strategy (levels 16-19)
|
||||
fix : bug #944 : multithreading with shared ditionary and large data, reported by @gsliepen
|
||||
cli : fix : content size written in header by default
|
||||
cli : fix : improved LZ4 format support, by @felixhandte
|
||||
cli : new : hidden command `-S`, to benchmark multiple files while generating one result per file
|
||||
api : fix : support large skippable frames, by @terrelln
|
||||
api : fix : streaming interface was adding a useless 3-bytes null block to small frames
|
||||
api : change : when setting `pledgedSrcSize`, use `ZSTD_CONTENTSIZE_UNKNOWN` macro value to mean "unknown"
|
||||
build: fix : compilation under rhel6 and centos6, reported by @pixelb
|
||||
build: added `check` target
|
||||
|
||||
v1.3.2 (Oct 10, 2017)
|
||||
new : long range mode, using --long command, by Stella Lau (@stellamplau)
|
||||
new : ability to generate and decode magicless frames (#591)
|
||||
changed : maximum nb of threads reduced to 200, to avoid address space exhaustion in 32-bits mode
|
||||
fix : multi-threading compression works with custom allocators
|
||||
fix : ZSTD_sizeof_CStream() was over-evaluating memory usage
|
||||
fix : a rare compression bug when compression generates very large distances and bunch of other conditions (only possible at --ultra -22)
|
||||
fix : 32-bits build can now decode large offsets (levels 21+)
|
||||
cli : added LZ4 frame support by default, by Felix Handte (@felixhandte)
|
||||
cli : improved --list output
|
||||
cli : new : can split input file for dictionary training, using command -B#
|
||||
cli : new : clean operation artefact on Ctrl-C interruption
|
||||
cli : fix : do not change /dev/null permissions when using command -t with root access, reported by @mike155 (#851)
|
||||
cli : fix : write file size in header in multiple-files mode
|
||||
api : added macro ZSTD_COMPRESSBOUND() for static allocation
|
||||
api : experimental : new advanced decompression API
|
||||
api : fix : sizeof_CCtx() used to over-estimate
|
||||
build: fix : no-multithread variant compiles without pool.c dependency, reported by Mitchell Blank Jr (@mitchblank) (#819)
|
||||
build: better compatibility with reproducible builds, by Bernhard M. Wiedemann (@bmwiedemann) (#818)
|
||||
example : added streaming_memory_usage
|
||||
license : changed /examples license to BSD + GPLv2
|
||||
license : fix a few header files to reflect new license (#825)
|
||||
|
||||
v1.3.1 (Aug 21, 2017)
|
||||
New license : BSD + GPLv2
|
||||
perf: substantially decreased memory usage in Multi-threading mode, thanks to reports by Tino Reichardt (@mcmilk)
|
||||
perf: Multi-threading supports up to 256 threads. Cap at 256 when more are requested (#760)
|
||||
cli : improved and fixed --list command, by @ib (#772)
|
||||
cli : command -vV to list supported formats, by @ib (#771)
|
||||
build : fixed binary variants, reported by @svenha (#788)
|
||||
build : fix Visual compilation for non x86/x64 targets, reported by Greg Slazinski (@GregSlazinski) (#718)
|
||||
API exp : breaking change : ZSTD_getframeHeader() provides more information
|
||||
API exp : breaking change : pinned down values of error codes
|
||||
doc : fixed huffman example, by Ulrich Kunitz (@ulikunitz)
|
||||
new : contrib/adaptive-compression, I/O driven compression strength, by Paul Cruz (@paulcruz74)
|
||||
new : contrib/long_distance_matching, statistics by Stella Lau (@stellamplau)
|
||||
updated : contrib/linux-kernel, by Nick Terrell (@terrelln)
|
||||
|
||||
v1.3.0 (Jul 6, 2017)
|
||||
cli : new : `--list` command, by Paul Cruz
|
||||
cli : changed : xz/lzma support enabled by default
|
||||
cli : changed : `-t *` continue processing list after a decompression error
|
||||
API : added : ZSTD_versionString()
|
||||
API : promoted to stable status : ZSTD_getFrameContentSize(), by Sean Purcell
|
||||
API exp : new advanced API : ZSTD_compress_generic(), ZSTD_CCtx_setParameter()
|
||||
API exp : new : API for static or external allocation : ZSTD_initStatic?Ctx()
|
||||
API exp : added : ZSTD_decompressBegin_usingDDict(), requested by Guy Riddle (#700)
|
||||
API exp : clarified memory estimation / measurement functions.
|
||||
API exp : changed : strongest strategy renamed ZSTD_btultra, fastest strategy ZSTD_fast set to 1
|
||||
tools : decodecorpus can generate random dictionary-compressed samples, by Paul Cruz
|
||||
new : contrib/seekable_format, demo and API, by Sean Purcell
|
||||
changed : contrib/linux-kernel, updated version and license, by Nick Terrell
|
||||
|
||||
v1.2.0 (May 5, 2017)
|
||||
cli : changed : Multithreading enabled by default (use target zstd-nomt or HAVE_THREAD=0 to disable)
|
||||
cli : new : command -T0 means "detect and use nb of cores", by Sean Purcell
|
||||
cli : new : zstdmt symlink hardwired to `zstd -T0`
|
||||
cli : new : command --threads=# (#671)
|
||||
cli : changed : cover dictionary builder by default, for improved quality, by Nick Terrell
|
||||
cli : new : commands --train-cover and --train-legacy, to select dictionary algorithm and parameters
|
||||
cli : experimental targets `zstd4` and `xzstd4`, with support for lz4 format, by Sean Purcell
|
||||
cli : fix : does not output compressed data on console
|
||||
cli : fix : ignore symbolic links unless --force specified,
|
||||
API : breaking change : ZSTD_createCDict_advanced(), only use compressionParameters as argument
|
||||
API : added : prototypes ZSTD_*_usingCDict_advanced(), for direct control over frameParameters.
|
||||
API : improved: ZSTDMT_compressCCtx() reduced memory usage
|
||||
API : fix : ZSTDMT_compressCCtx() now provides srcSize in header (#634)
|
||||
API : fix : src size stored in frame header is controlled at end of frame
|
||||
API : fix : enforced consistent rules for pledgedSrcSize==0 (#641)
|
||||
API : fix : error code "GENERIC" replaced by "dstSizeTooSmall" when appropriate
|
||||
build: improved cmake script, by @Majlen
|
||||
build: enabled Multi-threading support for *BSD, by Baptiste Daroussin
|
||||
tools: updated Paramgrill. Command -O# provides best parameters for sample and speed target.
|
||||
new : contrib/linux-kernel version, by Nick Terrell
|
||||
|
||||
v1.1.4 (Mar 18, 2017)
|
||||
cli : new : can compress in *.gz format, using --format=gzip command, by Przemyslaw Skibinski
|
||||
cli : new : advanced benchmark command --priority=rt
|
||||
cli : fix : write on sparse-enabled file systems in 32-bits mode, by @ds77
|
||||
cli : fix : --rm remains silent when input is stdin
|
||||
cli : experimental : xzstd, with support for xz/lzma decoding, by Przemyslaw Skibinski
|
||||
speed : improved decompression speed in streaming mode for single shot scenarios (+5%)
|
||||
memory: DDict (decompression dictionary) memory usage down from 150 KB to 20 KB
|
||||
arch: 32-bits variant able to generate and decode very long matches (>32 MB), by Sean Purcell
|
||||
API : new : ZSTD_findFrameCompressedSize(), ZSTD_getFrameContentSize(), ZSTD_findDecompressedSize()
|
||||
API : changed : dropped support of legacy versions <= v0.3 (can be changed by modifying ZSTD_LEGACY_SUPPORT value)
|
||||
build : new: meson build system in contrib/meson, by Dima Krasner
|
||||
build : improved cmake script, by @Majlen
|
||||
build : added -Wformat-security flag, as recommended by Padraig Brady
|
||||
doc : new : educational decoder, by Sean Purcell
|
||||
|
||||
v1.1.3 (Feb 7, 2017)
|
||||
cli : zstd can decompress .gz files (can be disabled with `make zstd-nogz` or `make HAVE_ZLIB=0`)
|
||||
cli : new : experimental target `make zstdmt`, with multi-threading support
|
||||
cli : new : improved dictionary builder "cover" (experimental), by Nick Terrell, based on prior work by Giuseppe Ottaviano.
|
||||
cli : new : advanced commands for detailed parameters, by Przemyslaw Skibinski
|
||||
cli : fix zstdless on Mac OS-X, by Andrew Janke
|
||||
cli : fix #232 "compress non-files"
|
||||
dictBuilder : improved dictionary generation quality, thanks to Nick Terrell
|
||||
API : new : lib/compress/ZSTDMT_compress.h multithreading API (experimental)
|
||||
API : new : ZSTD_create?Dict_byReference(), requested by Bartosz Taudul
|
||||
API : new : ZDICT_finalizeDictionary()
|
||||
API : fix : ZSTD_initCStream_usingCDict() properly writes dictID into frame header, by Gregory Szorc (#511)
|
||||
API : fix : all symbols properly exposed in libzstd, by Nick Terrell
|
||||
build : support for Solaris target, by Przemyslaw Skibinski
|
||||
doc : clarified specification, by Sean Purcell
|
||||
|
||||
v1.1.2 (Dec 15, 2016)
|
||||
API : streaming : decompression : changed : automatic implicit reset when chain-decoding new frames without init
|
||||
API : experimental : added : dictID retrieval functions, and ZSTD_initCStream_srcSize()
|
||||
API : zbuff : changed : prototypes now generate deprecation warnings
|
||||
lib : improved : faster decompression speed at ultra compression settings and 32-bits mode
|
||||
lib : changed : only public ZSTD_ symbols are now exposed
|
||||
lib : changed : reduced usage of stack memory
|
||||
lib : fixed : several corner case bugs, by Nick Terrell
|
||||
cli : new : gzstd, experimental version able to decode .gz files, by Przemyslaw Skibinski
|
||||
cli : new : preserve file attributes
|
||||
cli : new : added zstdless and zstdgrep tools
|
||||
cli : fixed : status displays total amount decoded, even for file consisting of multiple frames (like pzstd)
|
||||
cli : fixed : zstdcat
|
||||
zlib_wrapper : added support for gz* functions, by Przemyslaw Skibinski
|
||||
install : better compatibility with FreeBSD, by Dimitry Andric
|
||||
source tree : changed : zbuff source files moved to lib/deprecated
|
||||
|
||||
v1.1.1 (Nov 2, 2016)
|
||||
New : command -M#, --memory=, --memlimit=, --memlimit-decompress= to limit allowed memory consumption
|
||||
New : doc/zstd_manual.html, by Przemyslaw Skibinski
|
||||
Improved : slightly better compression ratio at --ultra levels (>= 20)
|
||||
Improved : better memory usage when using streaming compression API, thanks to @Rogier-5 report
|
||||
Added : API : ZSTD_initCStream_usingCDict(), ZSTD_initDStream_usingDDict() (experimental section)
|
||||
Added : example/multiple_streaming_compression.c
|
||||
Changed : zstd_errors.h is now installed within /include (and replaces errors_public.h)
|
||||
Updated man page
|
||||
Fixed : zstd-small, zstd-compress and zstd-decompress compilation targets
|
||||
|
||||
v1.1.0 (Sep 28, 2016)
|
||||
New : contrib/pzstd, parallel version of zstd, by Nick Terrell
|
||||
added : NetBSD install target (#338)
|
||||
Improved : speed for batches of small files
|
||||
Improved : speed of zlib wrapper, by Przemyslaw Skibinski
|
||||
Changed : libzstd on Windows supports legacy formats, by Christophe Chevalier
|
||||
Fixed : CLI -d output to stdout by default when input is stdin (#322)
|
||||
Fixed : CLI correctly detects console on Mac OS-X
|
||||
Fixed : CLI supports recursive mode `-r` on Mac OS-X
|
||||
Fixed : Legacy decoders use unified error codes, reported by benrg (#341), fixed by Przemyslaw Skibinski
|
||||
Fixed : compatibility with OpenBSD, reported by Juan Francisco Cantero Hurtado (#319)
|
||||
Fixed : compatibility with Hurd, by Przemyslaw Skibinski (#365)
|
||||
Fixed : zstd-pgo, reported by octoploid (#329)
|
||||
|
||||
v1.0.0 (Sep 1, 2016)
|
||||
Change Licensing, all project is now BSD, Copyright Facebook
|
||||
Small decompression speed improvement
|
||||
API : Streaming API supports legacy format
|
||||
API : ZDICT_getDictID(), ZSTD_sizeof_{CCtx, DCtx, CStream, DStream}(), ZSTD_setDStreamParameter()
|
||||
CLI supports legacy formats v0.4+
|
||||
Fixed : compression fails on certain huge files, reported by Jesse McGrew
|
||||
Enhanced documentation, by Przemyslaw Skibinski
|
||||
|
||||
v0.8.1 (Aug 18, 2016)
|
||||
New streaming API
|
||||
Changed : --ultra now enables levels beyond 19
|
||||
Changed : -i# now selects benchmark time in second
|
||||
Fixed : ZSTD_compress* can now compress > 4 GB in a single pass, reported by Nick Terrell
|
||||
Fixed : speed regression on specific patterns (#272)
|
||||
Fixed : support for Z_SYNC_FLUSH, by Dmitry Krot (#291)
|
||||
Fixed : ICC compilation, by Przemyslaw Skibinski
|
||||
|
||||
v0.8.0 (Aug 2, 2016)
|
||||
Improved : better speed on clang and gcc -O2, thanks to Eric Biggers
|
||||
New : Build on FreeBSD and DragonFly, thanks to JrMarino
|
||||
Changed : modified API : ZSTD_compressEnd()
|
||||
Fixed : legacy mode with ZSTD_HEAPMODE=0, by Christopher Bergqvist
|
||||
Fixed : premature end of frame when zero-sized raw block, reported by Eric Biggers
|
||||
Fixed : large dictionaries (> 384 KB), reported by Ilona Papava
|
||||
Fixed : checksum correctly checked in single-pass mode
|
||||
Fixed : combined --test amd --rm, reported by Andreas M. Nilsson
|
||||
Modified : minor compression level adaptations
|
||||
Updated : compression format specification to v0.2.0
|
||||
changed : zstd.h moved to /lib directory
|
||||
|
||||
v0.7.5 (Aug 1, 2016)
|
||||
Transition version, supporting decoding of v0.8.x
|
||||
|
||||
v0.7.4 (Jul 17, 2016)
|
||||
Added : homebrew for Mac, by Daniel Cade
|
||||
Added : more examples
|
||||
Fixed : segfault when using small dictionaries, reported by Felix Handte
|
||||
Modified : default compression level for CLI is now 3
|
||||
Updated : specification, to v0.1.1
|
||||
|
||||
v0.7.3 (Jul 9, 2016)
|
||||
New : compression format specification
|
||||
New : `--` separator, stating that all following arguments are file names. Suggested by Chip Turner.
|
||||
New : `ZSTD_getDecompressedSize()`
|
||||
New : OpenBSD target, by Juan Francisco Cantero Hurtado
|
||||
New : `examples` directory
|
||||
fixed : dictBuilder using HC levels, reported by Bartosz Taudul
|
||||
fixed : legacy support from ZSTD_decompress_usingDDict(), reported by Felix Handte
|
||||
fixed : multi-blocks decoding with intermediate uncompressed blocks, reported by Greg Slazinski
|
||||
modified : removed "mem.h" and "error_public.h" dependencies from "zstd.h" (experimental section)
|
||||
modified : legacy functions no longer need magic number
|
||||
|
||||
v0.7.2 (Jul 4, 2016)
|
||||
fixed : ZSTD_decompressBlock() using multiple consecutive blocks. Reported by Greg Slazinski.
|
||||
fixed : potential segfault on very large files (many gigabytes). Reported by Chip Turner.
|
||||
fixed : CLI displays system error message when destination file cannot be created (#231). Reported by Chip Turner.
|
||||
|
||||
v0.7.1 (Jun 23, 2016)
|
||||
fixed : ZBUFF_compressEnd() called multiple times with too small `dst` buffer, reported by Christophe Chevalier
|
||||
fixed : dictBuilder fails if first sample is too small, reported by Руслан Ковалёв
|
||||
fixed : corruption issue, reported by cj
|
||||
modified : checksum enabled by default in command line mode
|
||||
|
||||
v0.7.0 (Jun 17, 2016)
|
||||
New : Support for directory compression, using `-r`, thanks to Przemyslaw Skibinski
|
||||
New : Command `--rm`, to remove source file after successful de/compression
|
||||
New : Visual build scripts, by Christophe Chevalier
|
||||
New : Support for Sparse File-systems (do not use space for zero-filled sectors)
|
||||
New : Frame checksum support
|
||||
New : Support pass-through mode (when using `-df`)
|
||||
API : more efficient Dictionary API : `ZSTD_compress_usingCDict()`, `ZSTD_decompress_usingDDict()`
|
||||
API : create dictionary files from custom content, by Giuseppe Ottaviano
|
||||
API : support for custom malloc/free functions
|
||||
New : controllable Dictionary ID
|
||||
New : Support for skippable frames
|
||||
|
||||
v0.6.1 (May 13, 2016)
|
||||
New : zlib wrapper API, thanks to Przemyslaw Skibinski
|
||||
New : Ability to compile compressor / decompressor separately
|
||||
Changed : new lib directory structure
|
||||
Fixed : Legacy codec v0.5 compatible with dictionary decompression
|
||||
Fixed : Decoder corruption error (#173)
|
||||
Fixed : null-string roundtrip (#176)
|
||||
New : benchmark mode can select directory as input
|
||||
Experimental : midipix support, VMS support
|
||||
|
||||
v0.6.0 (Apr 13, 2016)
|
||||
Stronger high compression modes, thanks to Przemyslaw Skibinski
|
||||
API : ZSTD_getFrameParams() provides size of decompressed content
|
||||
New : highest compression modes require `--ultra` command to fully unleash their capacity
|
||||
Fixed : zstd cli return error code > 0 and removes dst file artifact when decompression fails, thanks to Chip Turner
|
||||
|
||||
v0.5.1 (Feb 18, 2016)
|
||||
New : Optimal parsing => Very high compression modes, thanks to Przemyslaw Skibinski
|
||||
Changed : Dictionary builder integrated into libzstd and zstd cli
|
||||
Changed (!) : zstd cli now uses "multiple input files" as default mode. See `zstd -h`.
|
||||
Fix : high compression modes for big-endian platforms
|
||||
New : zstd cli : `-t` | `--test` command
|
||||
|
||||
v0.5.0 (Feb 5, 2016)
|
||||
New : dictionary builder utility
|
||||
Changed : streaming & dictionary API
|
||||
Improved : better compression of small data
|
||||
|
||||
v0.4.7 (Jan 22, 2016)
|
||||
Improved : small compression speed improvement in HC mode
|
||||
Changed : `zstd_decompress.c` has ZSTD_LEGACY_SUPPORT to 0 by default
|
||||
fix : bt search bug
|
||||
|
||||
v0.4.6 (Jan 13, 2016)
|
||||
fix : fast compression mode on Windows
|
||||
New : cmake configuration file, thanks to Artyom Dymchenko
|
||||
Improved : high compression mode on repetitive data
|
||||
New : block-level API
|
||||
New : ZSTD_duplicateCCtx()
|
||||
|
||||
v0.4.5 (Dec 18, 2015)
|
||||
new : -m/--multiple : compress/decompress multiple files
|
||||
|
||||
v0.4.4 (Dec 14, 2015)
|
||||
Fixed : high compression modes for Windows 32 bits
|
||||
new : external dictionary API extended to buffered mode and accessible through command line
|
||||
new : windows DLL project, thanks to Christophe Chevalier
|
||||
|
||||
v0.4.3 (Dec 7, 2015)
|
||||
new : external dictionary API
|
||||
new : zstd-frugal
|
||||
|
||||
v0.4.2 (Dec 2, 2015)
|
||||
Generic minor improvements for small blocks
|
||||
Fixed : big-endian compatibility, by Peter Harris (#85)
|
||||
|
||||
v0.4.1 (Dec 1, 2015)
|
||||
Fixed : ZSTD_LEGACY_SUPPORT=0 build mode (reported by Luben)
|
||||
removed `zstd.c`
|
||||
|
||||
v0.4.0 (Nov 29, 2015)
|
||||
Command line utility compatible with high compression levels
|
||||
Removed zstdhc => merged into zstd
|
||||
Added : ZBUFF API (see zstd_buffered.h)
|
||||
Rolling buffer support
|
||||
|
||||
v0.3.6 (Nov 10, 2015)
|
||||
small blocks params
|
||||
|
||||
v0.3.5 (Nov 9, 2015)
|
||||
minor generic compression improvements
|
||||
|
||||
v0.3.4 (Nov 6, 2015)
|
||||
Faster fast cLevels
|
||||
|
||||
v0.3.3 (Nov 5, 2015)
|
||||
Small compression ratio improvement
|
||||
|
||||
v0.3.2 (Nov 2, 2015)
|
||||
Fixed Visual Studio
|
||||
|
||||
v0.3.1 (Nov 2, 2015)
|
||||
Small compression ratio improvement
|
||||
|
||||
v0.3 (Oct 30, 2015)
|
||||
HC mode : compression levels 2-26
|
||||
|
||||
v0.2.2 (Oct 28, 2015)
|
||||
Fix : Visual Studio 2013 & 2015 release compilation, by Christophe Chevalier
|
||||
|
||||
v0.2.1 (Oct 24, 2015)
|
||||
Fix : Read errors, advanced fuzzer tests, by Hanno Böck
|
||||
|
||||
v0.2.0 (Oct 22, 2015)
|
||||
**Breaking format change**
|
||||
Faster decompression speed
|
||||
Can still decode v0.1 format
|
||||
|
||||
v0.1.3 (Oct 15, 2015)
|
||||
fix uninitialization warning, reported by Evan Nemerson
|
||||
|
||||
v0.1.2 (Sep 11, 2015)
|
||||
frame concatenation support
|
||||
|
||||
v0.1.1 (Aug 27, 2015)
|
||||
fix compression bug
|
||||
detects write-flush errors
|
||||
|
||||
v0.1.0 (Aug 25, 2015)
|
||||
first release
|
||||
@ -0,0 +1,30 @@
|
||||
BSD License
|
||||
|
||||
For Zstandard software
|
||||
|
||||
Copyright (c) Meta Platforms, Inc. and affiliates. All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without modification,
|
||||
are permitted provided that the following conditions are met:
|
||||
|
||||
* Redistributions of source code must retain the above copyright notice, this
|
||||
list of conditions and the following disclaimer.
|
||||
|
||||
* Redistributions in binary form must reproduce the above copyright notice,
|
||||
this list of conditions and the following disclaimer in the documentation
|
||||
and/or other materials provided with the distribution.
|
||||
|
||||
* Neither the name Facebook, nor Meta, nor the names of its contributors may
|
||||
be used to endorse or promote products derived from this software without
|
||||
specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
|
||||
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
||||
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
|
||||
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
||||
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
||||
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
||||
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
@ -0,0 +1,223 @@
|
||||
<p align="center"><img src="https://raw.githubusercontent.com/facebook/zstd/dev/doc/images/zstd_logo86.png" alt="Zstandard"></p>
|
||||
|
||||
__Zstandard__, or `zstd` as short version, is a fast lossless compression algorithm,
|
||||
targeting real-time compression scenarios at zlib-level and better compression ratios.
|
||||
It's backed by a very fast entropy stage, provided by [Huff0 and FSE library](https://github.com/Cyan4973/FiniteStateEntropy).
|
||||
|
||||
Zstandard's format is stable and documented in [RFC8878](https://datatracker.ietf.org/doc/html/rfc8878). Multiple independent implementations are already available.
|
||||
This repository represents the reference implementation, provided as an open-source dual [BSD](LICENSE) and [GPLv2](COPYING) licensed **C** library,
|
||||
and a command line utility producing and decoding `.zst`, `.gz`, `.xz` and `.lz4` files.
|
||||
Should your project require another programming language,
|
||||
a list of known ports and bindings is provided on [Zstandard homepage](https://facebook.github.io/zstd/#other-languages).
|
||||
|
||||
**Development branch status:**
|
||||
|
||||
[![Build Status][travisDevBadge]][travisLink]
|
||||
[![Build status][CircleDevBadge]][CircleLink]
|
||||
[![Build status][CirrusDevBadge]][CirrusLink]
|
||||
[![Fuzzing Status][OSSFuzzBadge]][OSSFuzzLink]
|
||||
|
||||
[travisDevBadge]: https://api.travis-ci.com/facebook/zstd.svg?branch=dev "Continuous Integration test suite"
|
||||
[travisLink]: https://travis-ci.com/facebook/zstd
|
||||
[CircleDevBadge]: https://circleci.com/gh/facebook/zstd/tree/dev.svg?style=shield "Short test suite"
|
||||
[CircleLink]: https://circleci.com/gh/facebook/zstd
|
||||
[CirrusDevBadge]: https://api.cirrus-ci.com/github/facebook/zstd.svg?branch=dev
|
||||
[CirrusLink]: https://cirrus-ci.com/github/facebook/zstd
|
||||
[OSSFuzzBadge]: https://oss-fuzz-build-logs.storage.googleapis.com/badges/zstd.svg
|
||||
[OSSFuzzLink]: https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:zstd
|
||||
|
||||
## Benchmarks
|
||||
|
||||
For reference, several fast compression algorithms were tested and compared
|
||||
on a desktop running Ubuntu 20.04 (`Linux 5.11.0-41-generic`),
|
||||
with a Core i7-9700K CPU @ 4.9GHz,
|
||||
using [lzbench], an open-source in-memory benchmark by @inikep
|
||||
compiled with [gcc] 9.3.0,
|
||||
on the [Silesia compression corpus].
|
||||
|
||||
[lzbench]: https://github.com/inikep/lzbench
|
||||
[Silesia compression corpus]: https://sun.aei.polsl.pl//~sdeor/index.php?page=silesia
|
||||
[gcc]: https://gcc.gnu.org/
|
||||
|
||||
| Compressor name | Ratio | Compression| Decompress.|
|
||||
| --------------- | ------| -----------| ---------- |
|
||||
| **zstd 1.5.1 -1** | 2.887 | 530 MB/s | 1700 MB/s |
|
||||
| [zlib] 1.2.11 -1 | 2.743 | 95 MB/s | 400 MB/s |
|
||||
| brotli 1.0.9 -0 | 2.702 | 395 MB/s | 450 MB/s |
|
||||
| **zstd 1.5.1 --fast=1** | 2.437 | 600 MB/s | 2150 MB/s |
|
||||
| **zstd 1.5.1 --fast=3** | 2.239 | 670 MB/s | 2250 MB/s |
|
||||
| quicklz 1.5.0 -1 | 2.238 | 540 MB/s | 760 MB/s |
|
||||
| **zstd 1.5.1 --fast=4** | 2.148 | 710 MB/s | 2300 MB/s |
|
||||
| lzo1x 2.10 -1 | 2.106 | 660 MB/s | 845 MB/s |
|
||||
| [lz4] 1.9.3 | 2.101 | 740 MB/s | 4500 MB/s |
|
||||
| lzf 3.6 -1 | 2.077 | 410 MB/s | 830 MB/s |
|
||||
| snappy 1.1.9 | 2.073 | 550 MB/s | 1750 MB/s |
|
||||
|
||||
[zlib]: https://www.zlib.net/
|
||||
[lz4]: https://lz4.github.io/lz4/
|
||||
|
||||
The negative compression levels, specified with `--fast=#`,
|
||||
offer faster compression and decompression speed
|
||||
at the cost of compression ratio (compared to level 1).
|
||||
|
||||
Zstd can also offer stronger compression ratios at the cost of compression speed.
|
||||
Speed vs Compression trade-off is configurable by small increments.
|
||||
Decompression speed is preserved and remains roughly the same at all settings,
|
||||
a property shared by most LZ compression algorithms, such as [zlib] or lzma.
|
||||
|
||||
The following tests were run
|
||||
on a server running Linux Debian (`Linux version 4.14.0-3-amd64`)
|
||||
with a Core i7-6700K CPU @ 4.0GHz,
|
||||
using [lzbench], an open-source in-memory benchmark by @inikep
|
||||
compiled with [gcc] 7.3.0,
|
||||
on the [Silesia compression corpus].
|
||||
|
||||
Compression Speed vs Ratio | Decompression Speed
|
||||
---------------------------|--------------------
|
||||
 | 
|
||||
|
||||
A few other algorithms can produce higher compression ratios at slower speeds, falling outside of the graph.
|
||||
For a larger picture including slow modes, [click on this link](doc/images/DCspeed5.png).
|
||||
|
||||
|
||||
## The case for Small Data compression
|
||||
|
||||
Previous charts provide results applicable to typical file and stream scenarios (several MB). Small data comes with different perspectives.
|
||||
|
||||
The smaller the amount of data to compress, the more difficult it is to compress. This problem is common to all compression algorithms, and reason is, compression algorithms learn from past data how to compress future data. But at the beginning of a new data set, there is no "past" to build upon.
|
||||
|
||||
To solve this situation, Zstd offers a __training mode__, which can be used to tune the algorithm for a selected type of data.
|
||||
Training Zstandard is achieved by providing it with a few samples (one file per sample). The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression.
|
||||
Using this dictionary, the compression ratio achievable on small data improves dramatically.
|
||||
|
||||
The following example uses the `github-users` [sample set](https://github.com/facebook/zstd/releases/tag/v1.1.3), created from [github public API](https://developer.github.com/v3/users/#get-all-users).
|
||||
It consists of roughly 10K records weighing about 1KB each.
|
||||
|
||||
Compression Ratio | Compression Speed | Decompression Speed
|
||||
------------------|-------------------|--------------------
|
||||
 |  | 
|
||||
|
||||
|
||||
These compression gains are achieved while simultaneously providing _faster_ compression and decompression speeds.
|
||||
|
||||
Training works if there is some correlation in a family of small data samples. The more data-specific a dictionary is, the more efficient it is (there is no _universal dictionary_).
|
||||
Hence, deploying one dictionary per type of data will provide the greatest benefits.
|
||||
Dictionary gains are mostly effective in the first few KB. Then, the compression algorithm will gradually use previously decoded content to better compress the rest of the file.
|
||||
|
||||
### Dictionary compression How To:
|
||||
|
||||
1. Create the dictionary
|
||||
|
||||
`zstd --train FullPathToTrainingSet/* -o dictionaryName`
|
||||
|
||||
2. Compress with dictionary
|
||||
|
||||
`zstd -D dictionaryName FILE`
|
||||
|
||||
3. Decompress with dictionary
|
||||
|
||||
`zstd -D dictionaryName --decompress FILE.zst`
|
||||
|
||||
|
||||
## Build instructions
|
||||
|
||||
`make` is the officially maintained build system of this project.
|
||||
All other build systems are "compatible" and 3rd-party maintained,
|
||||
they may feature small differences in advanced options.
|
||||
When your system allows it, prefer using `make` to build `zstd` and `libzstd`.
|
||||
|
||||
### Makefile
|
||||
|
||||
If your system is compatible with standard `make` (or `gmake`),
|
||||
invoking `make` in root directory will generate `zstd` cli in root directory.
|
||||
It will also create `libzstd` into `lib/`.
|
||||
|
||||
Other available options include:
|
||||
- `make install` : create and install zstd cli, library and man pages
|
||||
- `make check` : create and run `zstd`, test its behavior on local platform
|
||||
|
||||
The `Makefile` follows the [GNU Standard Makefile conventions](https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html),
|
||||
allowing staged install, standard flags, directory variables and command variables.
|
||||
|
||||
For advanced use cases, specialized compilation flags which control binary generation
|
||||
are documented in [`lib/README.md`](lib/README.md#modular-build) for the `libzstd` library
|
||||
and in [`programs/README.md`](programs/README.md#compilation-variables) for the `zstd` CLI.
|
||||
|
||||
### cmake
|
||||
|
||||
A `cmake` project generator is provided within `build/cmake`.
|
||||
It can generate Makefiles or other build scripts
|
||||
to create `zstd` binary, and `libzstd` dynamic and static libraries.
|
||||
|
||||
By default, `CMAKE_BUILD_TYPE` is set to `Release`.
|
||||
|
||||
#### Support for Fat (Universal2) Output
|
||||
|
||||
`zstd` can be built and installed with support for both Apple Silicon (M1/M2) as well as Intel by using CMake's Universal2 support.
|
||||
To perform a Fat/Universal2 build and install use the following commands:
|
||||
|
||||
```bash
|
||||
cmake -B build-cmake-debug -S build/cmake -G Ninja -DCMAKE_OSX_ARCHITECTURES="x86_64;x86_64h;arm64"
|
||||
cd build-cmake-debug
|
||||
ninja
|
||||
sudo ninja install
|
||||
```
|
||||
|
||||
### Meson
|
||||
|
||||
A Meson project is provided within [`build/meson`](build/meson). Follow
|
||||
build instructions in that directory.
|
||||
|
||||
You can also take a look at [`.travis.yml`](.travis.yml) file for an
|
||||
example about how Meson is used to build this project.
|
||||
|
||||
Note that default build type is **release**.
|
||||
|
||||
### VCPKG
|
||||
You can build and install zstd [vcpkg](https://github.com/Microsoft/vcpkg/) dependency manager:
|
||||
|
||||
git clone https://github.com/Microsoft/vcpkg.git
|
||||
cd vcpkg
|
||||
./bootstrap-vcpkg.sh
|
||||
./vcpkg integrate install
|
||||
./vcpkg install zstd
|
||||
|
||||
The zstd port in vcpkg is kept up to date by Microsoft team members and community contributors.
|
||||
If the version is out of date, please [create an issue or pull request](https://github.com/Microsoft/vcpkg) on the vcpkg repository.
|
||||
|
||||
### Visual Studio (Windows)
|
||||
|
||||
Going into `build` directory, you will find additional possibilities:
|
||||
- Projects for Visual Studio 2005, 2008 and 2010.
|
||||
+ VS2010 project is compatible with VS2012, VS2013, VS2015 and VS2017.
|
||||
- Automated build scripts for Visual compiler by [@KrzysFR](https://github.com/KrzysFR), in `build/VS_scripts`,
|
||||
which will build `zstd` cli and `libzstd` library without any need to open Visual Studio solution.
|
||||
|
||||
### Buck
|
||||
|
||||
You can build the zstd binary via buck by executing: `buck build programs:zstd` from the root of the repo.
|
||||
The output binary will be in `buck-out/gen/programs/`.
|
||||
|
||||
## Testing
|
||||
|
||||
You can run quick local smoke tests by running `make check`.
|
||||
If you can't use `make`, execute the `playTest.sh` script from the `src/tests` directory.
|
||||
Two env variables `$ZSTD_BIN` and `$DATAGEN_BIN` are needed for the test script to locate the `zstd` and `datagen` binary.
|
||||
For information on CI testing, please refer to `TESTING.md`.
|
||||
|
||||
## Status
|
||||
|
||||
Zstandard is currently deployed within Facebook and many other large cloud infrastructures.
|
||||
It is run continuously to compress large amounts of data in multiple formats and use cases.
|
||||
Zstandard is considered safe for production environments.
|
||||
|
||||
## License
|
||||
|
||||
Zstandard is dual-licensed under [BSD](LICENSE) and [GPLv2](COPYING).
|
||||
|
||||
## Contributing
|
||||
|
||||
The `dev` branch is the one where all contributions are merged before reaching `release`.
|
||||
If you plan to propose a patch, please commit into the `dev` branch, or its own feature branch.
|
||||
Direct commit to `release` are not permitted.
|
||||
For more information, please read [CONTRIBUTING](CONTRIBUTING.md).
|
||||
@ -0,0 +1,41 @@
|
||||
# Alt-Svc
|
||||
|
||||
curl features support for the Alt-Svc: HTTP header.
|
||||
|
||||
## Enable Alt-Svc in build
|
||||
|
||||
`./configure --enable-alt-svc`
|
||||
|
||||
(enabled by default since 7.73.0)
|
||||
|
||||
## Standard
|
||||
|
||||
[RFC 7838](https://datatracker.ietf.org/doc/html/rfc7838)
|
||||
|
||||
# Alt-Svc cache file format
|
||||
|
||||
This is a text based file with one line per entry and each line consists of nine
|
||||
space separated fields.
|
||||
|
||||
## Example
|
||||
|
||||
h2 quic.tech 8443 h3-22 quic.tech 8443 "20190808 06:18:37" 0 0
|
||||
|
||||
## Fields
|
||||
|
||||
1. The ALPN id for the source origin
|
||||
2. The host name for the source origin
|
||||
3. The port number for the source origin
|
||||
4. The ALPN id for the destination host
|
||||
5. The host name for the destination host
|
||||
6. The host number for the destination host
|
||||
7. The expiration date and time of this entry within double quotes. The date format is "YYYYMMDD HH:MM:SS" and the time zone is GMT.
|
||||
8. Boolean (1 or 0) if "persist" was set for this entry
|
||||
9. Integer priority value (not currently used)
|
||||
|
||||
# TODO
|
||||
|
||||
- handle multiple response headers, when one of them says `clear` (should
|
||||
override them all)
|
||||
- using `Age:` value for caching age as per spec
|
||||
- `CURLALTSVC_IMMEDIATELY` support
|
||||
@ -0,0 +1,136 @@
|
||||
libcurl bindings
|
||||
================
|
||||
|
||||
Creative people have written bindings or interfaces for various environments
|
||||
and programming languages. Using one of these allows you to take advantage of
|
||||
curl powers from within your favourite language or system.
|
||||
|
||||
This is a list of all known interfaces as of this writing.
|
||||
|
||||
The bindings listed below are not part of the curl/libcurl distribution
|
||||
archives, but must be downloaded and installed separately.
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
|
||||
[Ada95](https://web.archive.org/web/20070403105909/www.almroth.com/adacurl/index.html) Written by Andreas Almroth
|
||||
|
||||
[Basic](https://scriptbasic.com/) ScriptBasic bindings written by Peter Verhas
|
||||
|
||||
C++: [curlpp](https://github.com/jpbarrette/curlpp/) Written by Jean-Philippe Barrette-LaPierre,
|
||||
[curlcpp](https://github.com/JosephP91/curlcpp) by Giuseppe Persico and [C++
|
||||
Requests](https://github.com/libcpr/cpr) by Huu Nguyen
|
||||
|
||||
[Ch](https://chcurl.sourceforge.net/) Written by Stephen Nestinger and Jonathan Rogado
|
||||
|
||||
Cocoa: [BBHTTP](https://github.com/biasedbit/BBHTTP) written by Bruno de Carvalho
|
||||
[curlhandle](https://github.com/karelia/curlhandle) Written by Dan Wood
|
||||
|
||||
Clojure: [clj-curl](https://github.com/lsevero/clj-curl) by Lucas Severo
|
||||
|
||||
[D](https://dlang.org/library/std/net/curl.html) Written by Kenneth Bogert
|
||||
|
||||
[Delphi](https://github.com/Mercury13/curl4delphi) Written by Mikhail Merkuryev
|
||||
|
||||
[Dylan](https://dylanlibs.sourceforge.net/) Written by Chris Double
|
||||
|
||||
[Eiffel](https://iron.eiffel.com/repository/20.11/package/ABEF6975-37AC-45FD-9C67-52D10BA0669B) Written by Eiffel Software
|
||||
|
||||
[Euphoria](https://web.archive.org/web/20050204080544/rays-web.com/eulibcurl.htm) Written by Ray Smith
|
||||
|
||||
[Falcon](http://www.falconpl.org/project_docs/curl/)
|
||||
|
||||
[Ferite](https://web.archive.org/web/20150102192018/ferite.org/) Written by Paul Querna
|
||||
|
||||
[Fortran](https://github.com/interkosmos/fortran-curl) Written by Philipp Engel
|
||||
|
||||
[Gambas](https://gambas.sourceforge.net/)
|
||||
|
||||
[glib/GTK+](https://web.archive.org/web/20100526203452/atterer.net/glibcurl) Written by Richard Atterer
|
||||
|
||||
Go: [go-curl](https://github.com/andelf/go-curl) by ShuYu Wang
|
||||
|
||||
[Guile](https://github.com/spk121/guile-curl) Written by Michael L. Gran
|
||||
|
||||
[Harbour](https://github.com/vszakats/hb/tree/main/contrib/hbcurl) Written by Viktor Szakats
|
||||
|
||||
[Haskell](https://hackage.haskell.org/package/curl) Written by Galois, Inc
|
||||
|
||||
[Hollywood](https://www.hollywood-mal.com/download.html) hURL by Andreas Falkenhahn
|
||||
|
||||
[Java](https://github.com/pjlegato/curl-java)
|
||||
|
||||
[Julia](https://github.com/JuliaWeb/LibCURL.jl) Written by Amit Murthy
|
||||
|
||||
[Kapito](https://github.com/puzza007/katipo) is an Erlang HTTP library around libcurl.
|
||||
|
||||
[Lisp](https://common-lisp.net/project/cl-curl/) Written by Liam Healy
|
||||
|
||||
Lua: [luacurl](https://web.archive.org/web/20201205052437/luacurl.luaforge.net/) by Alexander Marinov, [Lua-cURL](https://github.com/Lua-cURL) by Jürgen Hötzel
|
||||
|
||||
[Mono](https://web.archive.org/web/20070606064500/https://forge.novell.com/modules/xfmod/project/?libcurl-mono) Written by Jeffrey Phillips
|
||||
|
||||
[.NET](https://sourceforge.net/projects/libcurl-net/) libcurl-net by Jeffrey Phillips
|
||||
|
||||
[Nim](https://nimble.directory/pkg/libcurl) wrapper for libcurl
|
||||
|
||||
[node.js](https://github.com/JCMais/node-libcurl) node-libcurl by Jonathan Cardoso Machado
|
||||
|
||||
[Object-Pascal](https://web.archive.org/web/20020610214926/www.tekool.com/opcurl) Free Pascal, Delphi and Kylix binding written by Christophe Espern.
|
||||
|
||||
[OCaml](https://opam.ocaml.org/packages/ocurl/) Written by Lars Nilsson and ygrek
|
||||
|
||||
[Pascal](https://web.archive.org/web/20030804091414/houston.quik.com/jkp/curlpas/) Free Pascal, Delphi and Kylix binding written by Jeffrey Pohlmeyer.
|
||||
|
||||
Perl: [WWW::Curl](https://github.com/szbalint/WWW--Curl) Maintained by Cris
|
||||
Bailiff and Bálint Szilakszi,
|
||||
[perl6-net-curl](https://github.com/azawawi/perl6-net-curl) by Ahmad M. Zawawi
|
||||
[NET::Curl](https://metacpan.org/pod/Net::Curl) by Przemyslaw Iskra
|
||||
|
||||
[PHP](https://php.net/curl) Originally written by Sterling Hughes
|
||||
|
||||
[PostgreSQL](https://github.com/pramsey/pgsql-http) - HTTP client for PostgreSQL
|
||||
|
||||
[PostgreSQL](https://github.com/RekGRpth/pg_curl) - cURL client for PostgreSQL
|
||||
|
||||
[PureBasic](https://www.purebasic.com/documentation/http/index.html) uses libcurl in its "native" HTTP subsystem
|
||||
|
||||
[Python](http://pycurl.io/) PycURL by Kjetil Jacobsen
|
||||
|
||||
[Q](https://q-lang.sourceforge.net/) The libcurl module is part of the default install
|
||||
|
||||
[R](https://cran.r-project.org/package=curl)
|
||||
|
||||
[Rexx](https://rexxcurl.sourceforge.net/) Written Mark Hessling
|
||||
|
||||
[Ring](https://ring-lang.sourceforge.io/doc1.3/libcurl.html) RingLibCurl by Mahmoud Fayed
|
||||
|
||||
RPG, support for ILE/RPG on OS/400 is included in source distribution
|
||||
|
||||
Ruby: [curb](https://github.com/taf2/curb) written by Ross Bamford,
|
||||
[ruby-curl-multi](https://github.com/kball/curl_multi.rb) by Kristjan Petursson and Keith Rarick
|
||||
|
||||
[Rust](https://github.com/alexcrichton/curl-rust) curl-rust - by Carl Lerche
|
||||
|
||||
[Scheme](http://www.metapaper.net/lisovsky/web/curl/) Bigloo binding by Kirill Lisovsky
|
||||
|
||||
[Scilab](https://help.scilab.org/docs/current/fr_FR/getURL.html) binding by Sylvestre Ledru
|
||||
|
||||
[S-Lang](https://www.jedsoft.org/slang/modules/curl.html) by John E Davis
|
||||
|
||||
[Smalltalk](https://www.squeaksource.com/CurlPlugin/) Written by Danil Osipchuk
|
||||
|
||||
[SP-Forth](https://sourceforge.net/p/spf/spf/ci/master/tree/devel/~ac/lib/lin/curl/) Written by Andrey Cherezov
|
||||
|
||||
[SPL](https://web.archive.org/web/20210203022158/www.clifford.at/spl/spldoc/curl.html) Written by Clifford Wolf
|
||||
|
||||
[Tcl](https://web.archive.org/web/20160826011806/mirror.yellow5.com/tclcurl/) Tclcurl by Andrés García
|
||||
|
||||
[Visual Basic](https://sourceforge.net/projects/libcurl-vb/) libcurl-vb by Jeffrey Phillips
|
||||
|
||||
[Visual Foxpro](https://web.archive.org/web/20130730181523/www.ctl32.com.ar/libcurl.asp) by Carlos Alloatti
|
||||
|
||||
[wxWidgets](https://wxcode.sourceforge.net/components/wxcurl/) Written by Casey O'Donnell
|
||||
|
||||
[XBLite](https://web.archive.org/web/20060426150418/perso.wanadoo.fr/xblite/libraries.html) Written by David Szafranski
|
||||
|
||||
[Xojo](https://github.com/charonn0/RB-libcURL) Written by Andrew Lambert
|
||||
@ -0,0 +1,81 @@
|
||||
# bufref
|
||||
|
||||
This is an internal module for handling buffer references. A referenced
|
||||
buffer is associated with its destructor function that is implicitly called
|
||||
when the reference is invalidated. Once referenced, a buffer cannot be
|
||||
reallocated.
|
||||
|
||||
A data length is stored within the reference for binary data handling
|
||||
purposes; it is not used by the bufref API.
|
||||
|
||||
The `struct bufref` is used to hold data referencing a buffer. The members of
|
||||
that structure **MUST NOT** be accessed or modified without using the dedicated
|
||||
bufref API.
|
||||
|
||||
## `init`
|
||||
|
||||
```c
|
||||
void Curl_bufref_init(struct bufref *br);
|
||||
```
|
||||
|
||||
Initializes a `bufref` structure. This function **MUST** be called before any
|
||||
other operation is performed on the structure.
|
||||
|
||||
Upon completion, the referenced buffer is `NULL` and length is zero.
|
||||
|
||||
This function may also be called to bypass referenced buffer destruction while
|
||||
invalidating the current reference.
|
||||
|
||||
## `free`
|
||||
|
||||
```c
|
||||
void Curl_bufref_free(struct bufref *br);
|
||||
```
|
||||
|
||||
Destroys the previously referenced buffer using its destructor and
|
||||
reinitializes the structure for a possible subsequent reuse.
|
||||
|
||||
## `set`
|
||||
|
||||
```c
|
||||
void Curl_bufref_set(struct bufref *br, const void *buffer, size_t length,
|
||||
void (*destructor)(void *));
|
||||
```
|
||||
|
||||
Releases the previously referenced buffer, then assigns the new `buffer` to
|
||||
the structure, associated with its `destructor` function. The latter can be
|
||||
specified as `NULL`: this will be the case when the referenced buffer is
|
||||
static.
|
||||
|
||||
if `buffer` is NULL, `length` must be zero.
|
||||
|
||||
## `memdup`
|
||||
|
||||
```c
|
||||
CURLcode Curl_bufref_memdup(struct bufref *br, const void *data, size_t length);
|
||||
```
|
||||
|
||||
Releases the previously referenced buffer, then duplicates the `length`-byte
|
||||
`data` into a buffer allocated via `malloc()` and references the latter
|
||||
associated with destructor `curl_free()`.
|
||||
|
||||
An additional trailing byte is allocated and set to zero as a possible string
|
||||
null-terminator; it is not counted in the stored length.
|
||||
|
||||
Returns `CURLE_OK` if successful, else `CURLE_OUT_OF_MEMORY`.
|
||||
|
||||
## `ptr`
|
||||
|
||||
```c
|
||||
const unsigned char *Curl_bufref_ptr(const struct bufref *br);
|
||||
```
|
||||
|
||||
Returns a `const unsigned char *` to the referenced buffer.
|
||||
|
||||
## `len`
|
||||
|
||||
```c
|
||||
size_t Curl_bufref_len(const struct bufref *br);
|
||||
```
|
||||
|
||||
Returns the stored length of the referenced buffer.
|
||||
@ -0,0 +1,78 @@
|
||||
# The curl bug bounty
|
||||
|
||||
The curl project runs a bug bounty program in association with
|
||||
[HackerOne](https://www.hackerone.com) and the [Internet Bug
|
||||
Bounty](https://internetbugbounty.org).
|
||||
|
||||
## How does it work?
|
||||
|
||||
Start out by posting your suspected security vulnerability directly to [curl's
|
||||
HackerOne program](https://hackerone.com/curl).
|
||||
|
||||
After you have reported a security issue, it has been deemed credible, and a
|
||||
patch and advisory has been made public, you may be eligible for a bounty from
|
||||
this program. See the [SECURITY-PROCESS](SECURITY-PROCESS.md) document for how
|
||||
we work with security issues.
|
||||
|
||||
## What are the reward amounts?
|
||||
|
||||
The curl project offers monetary compensation for reported and published
|
||||
security vulnerabilities. The amount of money that is rewarded depends on how
|
||||
serious the flaw is determined to be.
|
||||
|
||||
Since 2021, the Bug Bounty is managed in association with the Internet Bug
|
||||
Bounty and they will set the reward amounts. If it would turn out that they
|
||||
set amounts that are way lower than we can accept, the curl project intends to
|
||||
"top up" rewards.
|
||||
|
||||
In 2022, typical "Medium" rated vulnerabilities have been rewarded 2,400 USD
|
||||
each.
|
||||
|
||||
## Who is eligible for a reward?
|
||||
|
||||
Everyone and anyone who reports a security problem in a released curl version
|
||||
that has not already been reported can ask for a bounty.
|
||||
|
||||
Dedicated - paid for - security audits that are performed in collaboration
|
||||
with curl developers are not eligible for bounties.
|
||||
|
||||
Vulnerabilities in features that are off by default and documented as
|
||||
experimental are not eligible for a reward.
|
||||
|
||||
The vulnerability has to be fixed and publicly announced (by the curl project)
|
||||
before a bug bounty will be considered.
|
||||
|
||||
Once the vulnerability has been published by curl, the researcher can request
|
||||
their bounty from the [Internet Bug Bounty](https://hackerone.com/ibb).
|
||||
|
||||
Bounties need to be requested within twelve months from the publication of the
|
||||
vulnerability.
|
||||
|
||||
## Product vulnerabilities only
|
||||
|
||||
This bug bounty only concerns the curl and libcurl products and thus their
|
||||
respective source codes - when running on existing hardware. It does not
|
||||
include curl documentation, curl websites, or other curl related
|
||||
infrastructure.
|
||||
|
||||
The curl security team is the sole arbiter if a reported flaw is subject to a
|
||||
bounty or not.
|
||||
|
||||
## How are vulnerabilities graded?
|
||||
|
||||
The grading of each reported vulnerability that makes a reward claim will be
|
||||
performed by the curl security team. The grading will be based on the CVSS
|
||||
(Common Vulnerability Scoring System) 3.0.
|
||||
|
||||
## How are reward amounts determined?
|
||||
|
||||
The curl security team gives the vulnerability a score or severity level, as
|
||||
mentioned above. The actual monetary reward amount is decided and paid by the
|
||||
Internet Bug Bounty..
|
||||
|
||||
## Regarding taxes, etc. on the bounties
|
||||
|
||||
In the event that the individual receiving a bug bounty needs to pay taxes on
|
||||
the reward money, the responsibility lies with the receiver. The curl project
|
||||
or its security team never actually receive any of this money, hold the money,
|
||||
or pay out the money.
|
||||
@ -0,0 +1,265 @@
|
||||
# BUGS
|
||||
|
||||
## There are still bugs
|
||||
|
||||
Curl and libcurl keep being developed. Adding features and changing code
|
||||
means that bugs will sneak in, no matter how hard we try to keep them out.
|
||||
|
||||
Of course there are lots of bugs left. And lots of misfeatures.
|
||||
|
||||
To help us make curl the stable and solid product we want it to be, we need
|
||||
bug reports and bug fixes.
|
||||
|
||||
## Where to report
|
||||
|
||||
If you cannot fix a bug yourself and submit a fix for it, try to report an as
|
||||
detailed report as possible to a curl mailing list to allow one of us to have
|
||||
a go at a solution. You can optionally also submit your problem in [curl's
|
||||
bug tracking system](https://github.com/curl/curl/issues).
|
||||
|
||||
Please read the rest of this document below first before doing that.
|
||||
|
||||
If you feel you need to ask around first, find a suitable [mailing list](
|
||||
https://curl.se/mail/) and post your questions there.
|
||||
|
||||
## Security bugs
|
||||
|
||||
If you find a bug or problem in curl or libcurl that you think has a security
|
||||
impact, for example a bug that can put users in danger or make them
|
||||
vulnerable if the bug becomes public knowledge, then please report that bug
|
||||
using our security development process.
|
||||
|
||||
Security related bugs or bugs that are suspected to have a security impact,
|
||||
should be reported on the [curl security tracker at
|
||||
HackerOne](https://hackerone.com/curl).
|
||||
|
||||
This ensures that the report reaches the curl security team so that they
|
||||
first can deal with the report away from the public to minimize the harm
|
||||
and impact it will have on existing users out there who might be using the
|
||||
vulnerable versions.
|
||||
|
||||
The curl project's process for handling security related issues is
|
||||
[documented separately](https://curl.se/dev/secprocess.html).
|
||||
|
||||
## What to report
|
||||
|
||||
When reporting a bug, you should include all information that will help us
|
||||
understand what is wrong, what you expected to happen and how to repeat the
|
||||
bad behavior. You therefore need to tell us:
|
||||
|
||||
- your operating system's name and version number
|
||||
|
||||
- what version of curl you are using (`curl -V` is fine)
|
||||
|
||||
- versions of the used libraries that libcurl is built to use
|
||||
|
||||
- what URL you were working with (if possible), at least which protocol
|
||||
|
||||
and anything and everything else you think matters. Tell us what you expected
|
||||
to happen, tell use what did happen, tell us how you could make it work
|
||||
another way. Dig around, try out, test. Then include all the tiny bits and
|
||||
pieces in your report. You will benefit from this yourself, as it will enable
|
||||
us to help you quicker and more accurately.
|
||||
|
||||
Since curl deals with networks, it often helps us if you include a protocol
|
||||
debug dump with your bug report. The output you get by using the `-v` or
|
||||
`--trace` options.
|
||||
|
||||
If curl crashed, causing a core dump (in Unix), there is hardly any use to
|
||||
send that huge file to anyone of us. Unless we have the same system setup as
|
||||
you, we cannot do much with it. Instead, we ask you to get a stack trace and
|
||||
send that (much smaller) output to us instead.
|
||||
|
||||
The address and how to subscribe to the mailing lists are detailed in the
|
||||
`MANUAL.md` file.
|
||||
|
||||
## libcurl problems
|
||||
|
||||
When you have written your own application with libcurl to perform transfers,
|
||||
it is even more important to be specific and detailed when reporting bugs.
|
||||
|
||||
Tell us the libcurl version and your operating system. Tell us the name and
|
||||
version of all relevant sub-components like for example the SSL library
|
||||
you are using and what name resolving your libcurl uses. If you use SFTP or
|
||||
SCP, the libssh2 version is relevant etc.
|
||||
|
||||
Showing us a real source code example repeating your problem is the best way
|
||||
to get our attention and it will greatly increase our chances to understand
|
||||
your problem and to work on a fix (if we agree it truly is a problem).
|
||||
|
||||
Lots of problems that appear to be libcurl problems are actually just abuses
|
||||
of the libcurl API or other malfunctions in your applications. It is advised
|
||||
that you run your problematic program using a memory debug tool like valgrind
|
||||
or similar before you post memory-related or "crashing" problems to us.
|
||||
|
||||
## Who will fix the problems
|
||||
|
||||
If the problems or bugs you describe are considered to be bugs, we want to
|
||||
have the problems fixed.
|
||||
|
||||
There are no developers in the curl project that are paid to work on bugs.
|
||||
All developers that take on reported bugs do this on a voluntary basis. We do
|
||||
it out of an ambition to keep curl and libcurl excellent products and out of
|
||||
pride.
|
||||
|
||||
Please do not assume that you can just lump over something to us and it will
|
||||
then magically be fixed after some given time. Most often we need feedback
|
||||
and help to understand what you have experienced and how to repeat a
|
||||
problem. Then we may only be able to assist YOU to debug the problem and to
|
||||
track down the proper fix.
|
||||
|
||||
We get reports from many people every month and each report can take a
|
||||
considerable amount of time to really go to the bottom with.
|
||||
|
||||
## How to get a stack trace
|
||||
|
||||
First, you must make sure that you compile all sources with `-g` and that you
|
||||
do not 'strip' the final executable. Try to avoid optimizing the code as well,
|
||||
remove `-O`, `-O2` etc from the compiler options.
|
||||
|
||||
Run the program until it cores.
|
||||
|
||||
Run your debugger on the core file, like `<debugger> curl
|
||||
core`. `<debugger>` should be replaced with the name of your debugger, in
|
||||
most cases that will be `gdb`, but `dbx` and others also occur.
|
||||
|
||||
When the debugger has finished loading the core file and presents you a
|
||||
prompt, enter `where` (without quotes) and press return.
|
||||
|
||||
The list that is presented is the stack trace. If everything worked, it is
|
||||
supposed to contain the chain of functions that were called when curl
|
||||
crashed. Include the stack trace with your detailed bug report, it will help a
|
||||
lot.
|
||||
|
||||
## Bugs in libcurl bindings
|
||||
|
||||
There will of course pop up bugs in libcurl bindings. You should then
|
||||
primarily approach the team that works on that particular binding and see
|
||||
what you can do to help them fix the problem.
|
||||
|
||||
If you suspect that the problem exists in the underlying libcurl, then please
|
||||
convert your program over to plain C and follow the steps outlined above.
|
||||
|
||||
## Bugs in old versions
|
||||
|
||||
The curl project typically releases new versions every other month, and we
|
||||
fix several hundred bugs per year. For a huge table of releases, number of
|
||||
bug fixes and more, see: https://curl.se/docs/releases.html
|
||||
|
||||
The developers in the curl project do not have bandwidth or energy enough to
|
||||
maintain several branches or to spend much time on hunting down problems in
|
||||
old versions when chances are we already fixed them or at least that they have
|
||||
changed nature and appearance in later versions.
|
||||
|
||||
When you experience a problem and want to report it, you really SHOULD
|
||||
include the version number of the curl you are using when you experience the
|
||||
issue. If that version number shows us that you are using an out-of-date curl,
|
||||
you should also try out a modern curl version to see if the problem persists
|
||||
or how/if it has changed in appearance.
|
||||
|
||||
Even if you cannot immediately upgrade your application/system to run the
|
||||
latest curl version, you can most often at least run a test version or
|
||||
experimental build or similar, to get this confirmed or not.
|
||||
|
||||
At times people insist that they cannot upgrade to a modern curl version, but
|
||||
instead, they "just want the bug fixed". That is fine, just do not count on us
|
||||
spending many cycles on trying to identify which single commit, if that is
|
||||
even possible, that at some point in the past fixed the problem you are now
|
||||
experiencing.
|
||||
|
||||
Security wise, it is almost always a bad idea to lag behind the current curl
|
||||
versions by a lot. We keep discovering and reporting security problems
|
||||
over time see you can see in [this
|
||||
table](https://curl.se/docs/vulnerabilities.html)
|
||||
|
||||
# Bug fixing procedure
|
||||
|
||||
## What happens on first filing
|
||||
|
||||
When a new issue is posted in the issue tracker or on the mailing list, the
|
||||
team of developers first needs to see the report. Maybe they took the day off,
|
||||
maybe they are off in the woods hunting. Have patience. Allow at least a few
|
||||
days before expecting someone to have responded.
|
||||
|
||||
In the issue tracker, you can expect that some labels will be set on the issue
|
||||
to help categorize it.
|
||||
|
||||
## First response
|
||||
|
||||
If your issue/bug report was not perfect at once (and few are), chances are
|
||||
that someone will ask follow-up questions. Which version did you use? Which
|
||||
options did you use? How often does the problem occur? How can we reproduce
|
||||
this problem? Which protocols does it involve? Or perhaps much more specific
|
||||
and deep diving questions. It all depends on your specific issue.
|
||||
|
||||
You should then respond to these follow-up questions and provide more info
|
||||
about the problem, so that we can help you figure it out. Or maybe you can
|
||||
help us figure it out. An active back-and-forth communication is important
|
||||
and the key for finding a cure and landing a fix.
|
||||
|
||||
## Not reproducible
|
||||
|
||||
We may require further work from you who actually see or experience the
|
||||
problem if we cannot reproduce it and cannot understand it even after having
|
||||
gotten all the info we need and having studied the source code over again.
|
||||
|
||||
## Unresponsive
|
||||
|
||||
If the problem have not been understood or reproduced, and there is nobody
|
||||
responding to follow-up questions or questions asking for clarifications or
|
||||
for discussing possible ways to move forward with the task, we take that as a
|
||||
strong suggestion that the bug is unimportant.
|
||||
|
||||
Unimportant issues will be closed as inactive sooner or later as they cannot
|
||||
be fixed. The inactivity period (waiting for responses) should not be shorter
|
||||
than two weeks but may extend months.
|
||||
|
||||
## Lack of time/interest
|
||||
|
||||
Bugs that are filed and are understood can unfortunately end up in the
|
||||
"nobody cares enough about it to work on it" category. Such bugs are
|
||||
perfectly valid problems that *should* get fixed but apparently are not. We
|
||||
try to mark such bugs as `KNOWN_BUGS material` after a time of inactivity and
|
||||
if no activity is noticed after yet some time those bugs are added to the
|
||||
`KNOWN_BUGS` document and are closed in the issue tracker.
|
||||
|
||||
## `KNOWN_BUGS`
|
||||
|
||||
This is a list of known bugs. Bugs we know exist and that have been pointed
|
||||
out but that have not yet been fixed. The reasons for why they have not been
|
||||
fixed can involve anything really, but the primary reason is that nobody has
|
||||
considered these problems to be important enough to spend the necessary time
|
||||
and effort to have them fixed.
|
||||
|
||||
The `KNOWN_BUGS` items are always up for grabs and we love the ones who bring
|
||||
one of them back to life and offer solutions to them.
|
||||
|
||||
The `KNOWN_BUGS` document has a sibling document known as `TODO`.
|
||||
|
||||
## `TODO`
|
||||
|
||||
Issues that are filed or reported that are not really bugs but more missing
|
||||
features or ideas for future improvements and so on are marked as
|
||||
'enhancement' or 'feature-request' and will be added to the `TODO` document
|
||||
and the issues are closed. We do not keep TODO items open in the issue
|
||||
tracker.
|
||||
|
||||
The `TODO` document is full of ideas and suggestions of what we can add or
|
||||
fix one day. You are always encouraged and free to grab one of those items and
|
||||
take up a discussion with the curl development team on how that could be
|
||||
implemented or provided in the project so that you can work on ticking it odd
|
||||
that document.
|
||||
|
||||
If an issue is rather a bug and not a missing feature or functionality, it is
|
||||
listed in `KNOWN_BUGS` instead.
|
||||
|
||||
## Closing off stalled bugs
|
||||
|
||||
The [issue and pull request trackers](https://github.com/curl/curl) only
|
||||
hold "active" entries open (using a non-precise definition of what active
|
||||
actually is, but they are at least not completely dead). Those that are
|
||||
abandoned or in other ways dormant will be closed and sometimes added to
|
||||
`TODO` and `KNOWN_BUGS` instead.
|
||||
|
||||
This way, we only have "active" issues open on GitHub. Irrelevant issues and
|
||||
pull requests will not distract developers or casual visitors.
|
||||
@ -0,0 +1,182 @@
|
||||
# checksrc
|
||||
|
||||
This is the tool we use within the curl project to scan C source code and
|
||||
check that it adheres to our [Source Code Style guide](CODE_STYLE.md).
|
||||
|
||||
## Usage
|
||||
|
||||
checksrc.pl [options] [file1] [file2] ...
|
||||
|
||||
## Command line options
|
||||
|
||||
`-W[file]` skip that file and exclude it from being checked. Helpful
|
||||
when, for example, one of the files is generated.
|
||||
|
||||
`-D[dir]` directory name to prepend to file names when accessing them.
|
||||
|
||||
`-h` shows the help output, that also lists all recognized warnings
|
||||
|
||||
## What does `checksrc` warn for?
|
||||
|
||||
`checksrc` does not check and verify the code against the entire style guide.
|
||||
The script is an effort to detect the most common mistakes and syntax mistakes
|
||||
that contributors make before they get accustomed to our code style. Heck,
|
||||
many of us regulars do the mistakes too and this script helps us keep the code
|
||||
in shape.
|
||||
|
||||
checksrc.pl -h
|
||||
|
||||
Lists how to use the script and it lists all existing warnings it has and
|
||||
problems it detects. At the time of this writing, the existing `checksrc`
|
||||
warnings are:
|
||||
|
||||
- `ASSIGNWITHINCONDITION`: Assignment within a conditional expression. The
|
||||
code style mandates the assignment to be done outside of it.
|
||||
|
||||
- `ASTERISKNOSPACE`: A pointer was declared like `char* name` instead of the
|
||||
more appropriate `char *name` style. The asterisk should sit next to the
|
||||
name.
|
||||
|
||||
- `ASTERISKSPACE`: A pointer was declared like `char * name` instead of the
|
||||
more appropriate `char *name` style. The asterisk should sit right next to
|
||||
the name without a space in between.
|
||||
|
||||
- `BADCOMMAND`: There's a bad `checksrc` instruction in the code. See the
|
||||
**Ignore certain warnings** section below for details.
|
||||
|
||||
- `BANNEDFUNC`: A banned function was used. The functions sprintf, vsprintf,
|
||||
strcat, strncat, gets are **never** allowed in curl source code.
|
||||
|
||||
- `BRACEELSE`: '} else' on the same line. The else is supposed to be on the
|
||||
following line.
|
||||
|
||||
- `BRACEPOS`: wrong position for an open brace (`{`).
|
||||
|
||||
- `BRACEWHILE`: more than once space between end brace and while keyword
|
||||
|
||||
- `COMMANOSPACE`: a comma without following space
|
||||
|
||||
- `COPYRIGHT`: the file is missing a copyright statement
|
||||
|
||||
- `CPPCOMMENTS`: `//` comment detected, that is not C89 compliant
|
||||
|
||||
- `DOBRACE`: only use one space after do before open brace
|
||||
|
||||
- `EMPTYLINEBRACE`: found empty line before open brace
|
||||
|
||||
- `EQUALSNOSPACE`: no space after `=` sign
|
||||
|
||||
- `EQUALSNULL`: comparison with `== NULL` used in if/while. We use `!var`.
|
||||
|
||||
- `EXCLAMATIONSPACE`: space found after exclamations mark
|
||||
|
||||
- `FOPENMODE`: `fopen()` needs a macro for the mode string, use it
|
||||
|
||||
- `INDENTATION`: detected a wrong start column for code. Note that this
|
||||
warning only checks some specific places and will certainly miss many bad
|
||||
indentations.
|
||||
|
||||
- `LONGLINE`: A line is longer than 79 columns.
|
||||
|
||||
- `MULTISPACE`: Multiple spaces were found where only one should be used.
|
||||
|
||||
- `NOSPACEEQUALS`: An equals sign was found without preceding space. We prefer
|
||||
`a = 2` and *not* `a=2`.
|
||||
|
||||
- `NOTEQUALSZERO`: check found using `!= 0`. We use plain `if(var)`.
|
||||
|
||||
- `ONELINECONDITION`: do not put the conditional block on the same line as `if()`
|
||||
|
||||
- `OPENCOMMENT`: File ended with a comment (`/*`) still "open".
|
||||
|
||||
- `PARENBRACE`: `){` was used without sufficient space in between.
|
||||
|
||||
- `RETURNNOSPACE`: `return` was used without space between the keyword and the
|
||||
following value.
|
||||
|
||||
- `SEMINOSPACE`: There was no space (or newline) following a semicolon.
|
||||
|
||||
- `SIZEOFNOPAREN`: Found use of sizeof without parentheses. We prefer
|
||||
`sizeof(int)` style.
|
||||
|
||||
- `SNPRINTF` - Found use of `snprintf()`. Since we use an internal replacement
|
||||
with a different return code etc, we prefer `msnprintf()`.
|
||||
|
||||
- `SPACEAFTERPAREN`: there was a space after open parenthesis, `( text`.
|
||||
|
||||
- `SPACEBEFORECLOSE`: there was a space before a close parenthesis, `text )`.
|
||||
|
||||
- `SPACEBEFORECOMMA`: there was a space before a comma, `one , two`.
|
||||
|
||||
- `SPACEBEFOREPAREN`: there was a space before an open parenthesis, `if (`,
|
||||
where one was not expected
|
||||
|
||||
- `SPACESEMICOLON`: there was a space before semicolon, ` ;`.
|
||||
|
||||
- `TABS`: TAB characters are not allowed
|
||||
|
||||
- `TRAILINGSPACE`: Trailing whitespace on the line
|
||||
|
||||
- `TYPEDEFSTRUCT`: we frown upon (most) typedefed structs
|
||||
|
||||
- `UNUSEDIGNORE`: a `checksrc` inlined warning ignore was asked for but not
|
||||
used, that is an ignore that should be removed or changed to get used.
|
||||
|
||||
### Extended warnings
|
||||
|
||||
Some warnings are quite computationally expensive to perform, so they are
|
||||
turned off by default. To enable these warnings, place a `.checksrc` file in
|
||||
the directory where they should be activated with commands to enable the
|
||||
warnings you are interested in. The format of the file is to enable one
|
||||
warning per line like so: `enable <EXTENDEDWARNING>`
|
||||
|
||||
Currently these are the extended warnings which can be enabled:
|
||||
|
||||
- `COPYRIGHTYEAR`: the current changeset has not updated the copyright year in
|
||||
the source file
|
||||
|
||||
- `STRERROR`: use of banned function strerror()
|
||||
|
||||
## Ignore certain warnings
|
||||
|
||||
Due to the nature of the source code and the flaws of the `checksrc` tool,
|
||||
there is sometimes a need to ignore specific warnings. `checksrc` allows a few
|
||||
different ways to do this.
|
||||
|
||||
### Inline ignore
|
||||
|
||||
You can control what to ignore within a specific source file by providing
|
||||
instructions to `checksrc` in the source code itself. See examples below. The
|
||||
instruction can ask to ignore a specific warning a specific number of times or
|
||||
you ignore all of them until you mark the end of the ignored section.
|
||||
|
||||
Inline ignores are only done for that single specific source code file.
|
||||
|
||||
Example
|
||||
|
||||
/* !checksrc! disable LONGLINE all */
|
||||
|
||||
This will ignore the warning for overly long lines until it is re-enabled with:
|
||||
|
||||
/* !checksrc! enable LONGLINE */
|
||||
|
||||
If the enabling is not performed before the end of the file, it will be enabled
|
||||
automatically for the next file.
|
||||
|
||||
You can also opt to ignore just N violations so that if you have a single long
|
||||
line you just cannot shorten and is agreed to be fine anyway:
|
||||
|
||||
/* !checksrc! disable LONGLINE 1 */
|
||||
|
||||
... and the warning for long lines will be enabled again automatically after
|
||||
it has ignored that single warning. The number `1` can of course be changed to
|
||||
any other integer number. It can be used to make sure only the exact intended
|
||||
instances are ignored and nothing extra.
|
||||
|
||||
### Directory wide ignore patterns
|
||||
|
||||
This is a method we have transitioned away from. Use inline ignores as far as
|
||||
possible.
|
||||
|
||||
Make a `checksrc.skip` file in the directory of the source code with the
|
||||
false positive, and include the full offending line into this file.
|
||||
@ -0,0 +1,591 @@
|
||||
# Ciphers
|
||||
|
||||
With curl's options
|
||||
[`CURLOPT_SSL_CIPHER_LIST`](https://curl.se/libcurl/c/CURLOPT_SSL_CIPHER_LIST.html)
|
||||
and
|
||||
[`--ciphers`](https://curl.se/docs/manpage.html#--ciphers)
|
||||
users can control which ciphers to consider when negotiating TLS connections.
|
||||
|
||||
TLS 1.3 ciphers are supported since curl 7.61 for OpenSSL 1.1.1+, and since
|
||||
curl 7.85 for Schannel with options
|
||||
[`CURLOPT_TLS13_CIPHERS`](https://curl.se/libcurl/c/CURLOPT_TLS13_CIPHERS.html)
|
||||
and
|
||||
[`--tls13-ciphers`](https://curl.se/docs/manpage.html#--tls13-ciphers)
|
||||
. If you are using a different SSL backend you can try setting TLS 1.3 cipher
|
||||
suites by using the respective regular cipher option.
|
||||
|
||||
The names of the known ciphers differ depending on which TLS backend that
|
||||
libcurl was built to use. This is an attempt to list known cipher names.
|
||||
|
||||
## OpenSSL
|
||||
|
||||
(based on [OpenSSL docs](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html))
|
||||
|
||||
When specifying multiple cipher names, separate them with colon (`:`).
|
||||
|
||||
### SSL3 cipher suites
|
||||
|
||||
`NULL-MD5`
|
||||
`NULL-SHA`
|
||||
`RC4-MD5`
|
||||
`RC4-SHA`
|
||||
`IDEA-CBC-SHA`
|
||||
`DES-CBC3-SHA`
|
||||
`DH-DSS-DES-CBC3-SHA`
|
||||
`DH-RSA-DES-CBC3-SHA`
|
||||
`DHE-DSS-DES-CBC3-SHA`
|
||||
`DHE-RSA-DES-CBC3-SHA`
|
||||
`ADH-RC4-MD5`
|
||||
`ADH-DES-CBC3-SHA`
|
||||
|
||||
### TLS v1.0 cipher suites
|
||||
|
||||
`NULL-MD5`
|
||||
`NULL-SHA`
|
||||
`RC4-MD5`
|
||||
`RC4-SHA`
|
||||
`IDEA-CBC-SHA`
|
||||
`DES-CBC3-SHA`
|
||||
`DHE-DSS-DES-CBC3-SHA`
|
||||
`DHE-RSA-DES-CBC3-SHA`
|
||||
`ADH-RC4-MD5`
|
||||
`ADH-DES-CBC3-SHA`
|
||||
|
||||
### AES cipher suites from RFC3268, extending TLS v1.0
|
||||
|
||||
`AES128-SHA`
|
||||
`AES256-SHA`
|
||||
`DH-DSS-AES128-SHA`
|
||||
`DH-DSS-AES256-SHA`
|
||||
`DH-RSA-AES128-SHA`
|
||||
`DH-RSA-AES256-SHA`
|
||||
`DHE-DSS-AES128-SHA`
|
||||
`DHE-DSS-AES256-SHA`
|
||||
`DHE-RSA-AES128-SHA`
|
||||
`DHE-RSA-AES256-SHA`
|
||||
`ADH-AES128-SHA`
|
||||
`ADH-AES256-SHA`
|
||||
|
||||
### SEED cipher suites from RFC4162, extending TLS v1.0
|
||||
|
||||
`SEED-SHA`
|
||||
`DH-DSS-SEED-SHA`
|
||||
`DH-RSA-SEED-SHA`
|
||||
`DHE-DSS-SEED-SHA`
|
||||
`DHE-RSA-SEED-SHA`
|
||||
`ADH-SEED-SHA`
|
||||
|
||||
### GOST cipher suites, extending TLS v1.0
|
||||
|
||||
`GOST94-GOST89-GOST89`
|
||||
`GOST2001-GOST89-GOST89`
|
||||
`GOST94-NULL-GOST94`
|
||||
`GOST2001-NULL-GOST94`
|
||||
|
||||
### Elliptic curve cipher suites
|
||||
|
||||
`ECDHE-RSA-NULL-SHA`
|
||||
`ECDHE-RSA-RC4-SHA`
|
||||
`ECDHE-RSA-DES-CBC3-SHA`
|
||||
`ECDHE-RSA-AES128-SHA`
|
||||
`ECDHE-RSA-AES256-SHA`
|
||||
`ECDHE-ECDSA-NULL-SHA`
|
||||
`ECDHE-ECDSA-RC4-SHA`
|
||||
`ECDHE-ECDSA-DES-CBC3-SHA`
|
||||
`ECDHE-ECDSA-AES128-SHA`
|
||||
`ECDHE-ECDSA-AES256-SHA`
|
||||
`AECDH-NULL-SHA`
|
||||
`AECDH-RC4-SHA`
|
||||
`AECDH-DES-CBC3-SHA`
|
||||
`AECDH-AES128-SHA`
|
||||
`AECDH-AES256-SHA`
|
||||
|
||||
### TLS v1.2 cipher suites
|
||||
|
||||
`NULL-SHA256`
|
||||
`AES128-SHA256`
|
||||
`AES256-SHA256`
|
||||
`AES128-GCM-SHA256`
|
||||
`AES256-GCM-SHA384`
|
||||
`DH-RSA-AES128-SHA256`
|
||||
`DH-RSA-AES256-SHA256`
|
||||
`DH-RSA-AES128-GCM-SHA256`
|
||||
`DH-RSA-AES256-GCM-SHA384`
|
||||
`DH-DSS-AES128-SHA256`
|
||||
`DH-DSS-AES256-SHA256`
|
||||
`DH-DSS-AES128-GCM-SHA256`
|
||||
`DH-DSS-AES256-GCM-SHA384`
|
||||
`DHE-RSA-AES128-SHA256`
|
||||
`DHE-RSA-AES256-SHA256`
|
||||
`DHE-RSA-AES128-GCM-SHA256`
|
||||
`DHE-RSA-AES256-GCM-SHA384`
|
||||
`DHE-DSS-AES128-SHA256`
|
||||
`DHE-DSS-AES256-SHA256`
|
||||
`DHE-DSS-AES128-GCM-SHA256`
|
||||
`DHE-DSS-AES256-GCM-SHA384`
|
||||
`ECDHE-RSA-AES128-SHA256`
|
||||
`ECDHE-RSA-AES256-SHA384`
|
||||
`ECDHE-RSA-AES128-GCM-SHA256`
|
||||
`ECDHE-RSA-AES256-GCM-SHA384`
|
||||
`ECDHE-ECDSA-AES128-SHA256`
|
||||
`ECDHE-ECDSA-AES256-SHA384`
|
||||
`ECDHE-ECDSA-AES128-GCM-SHA256`
|
||||
`ECDHE-ECDSA-AES256-GCM-SHA384`
|
||||
`ADH-AES128-SHA256`
|
||||
`ADH-AES256-SHA256`
|
||||
`ADH-AES128-GCM-SHA256`
|
||||
`ADH-AES256-GCM-SHA384`
|
||||
`AES128-CCM`
|
||||
`AES256-CCM`
|
||||
`DHE-RSA-AES128-CCM`
|
||||
`DHE-RSA-AES256-CCM`
|
||||
`AES128-CCM8`
|
||||
`AES256-CCM8`
|
||||
`DHE-RSA-AES128-CCM8`
|
||||
`DHE-RSA-AES256-CCM8`
|
||||
`ECDHE-ECDSA-AES128-CCM`
|
||||
`ECDHE-ECDSA-AES256-CCM`
|
||||
`ECDHE-ECDSA-AES128-CCM8`
|
||||
`ECDHE-ECDSA-AES256-CCM8`
|
||||
|
||||
### Camellia HMAC-Based cipher suites from RFC6367, extending TLS v1.2
|
||||
|
||||
`ECDHE-ECDSA-CAMELLIA128-SHA256`
|
||||
`ECDHE-ECDSA-CAMELLIA256-SHA384`
|
||||
`ECDHE-RSA-CAMELLIA128-SHA256`
|
||||
`ECDHE-RSA-CAMELLIA256-SHA384`
|
||||
|
||||
### TLS 1.3 cipher suites
|
||||
|
||||
(Note these ciphers are set with `CURLOPT_TLS13_CIPHERS` and `--tls13-ciphers`)
|
||||
|
||||
`TLS_AES_256_GCM_SHA384`
|
||||
`TLS_CHACHA20_POLY1305_SHA256`
|
||||
`TLS_AES_128_GCM_SHA256`
|
||||
`TLS_AES_128_CCM_8_SHA256`
|
||||
`TLS_AES_128_CCM_SHA256`
|
||||
|
||||
## NSS
|
||||
|
||||
### Totally insecure
|
||||
|
||||
`rc4`
|
||||
`rc4-md5`
|
||||
`rc4export`
|
||||
`rc2`
|
||||
`rc2export`
|
||||
`des`
|
||||
`desede3`
|
||||
|
||||
### SSL3/TLS cipher suites
|
||||
|
||||
`rsa_rc4_128_md5`
|
||||
`rsa_rc4_128_sha`
|
||||
`rsa_3des_sha`
|
||||
`rsa_des_sha`
|
||||
`rsa_rc4_40_md5`
|
||||
`rsa_rc2_40_md5`
|
||||
`rsa_null_md5`
|
||||
`rsa_null_sha`
|
||||
`fips_3des_sha`
|
||||
`fips_des_sha`
|
||||
`fortezza`
|
||||
`fortezza_rc4_128_sha`
|
||||
`fortezza_null`
|
||||
|
||||
### TLS 1.0 Exportable 56-bit Cipher Suites
|
||||
|
||||
`rsa_des_56_sha`
|
||||
`rsa_rc4_56_sha`
|
||||
|
||||
### AES ciphers
|
||||
|
||||
`dhe_dss_aes_128_cbc_sha`
|
||||
`dhe_dss_aes_256_cbc_sha`
|
||||
`dhe_rsa_aes_128_cbc_sha`
|
||||
`dhe_rsa_aes_256_cbc_sha`
|
||||
`rsa_aes_128_sha`
|
||||
`rsa_aes_256_sha`
|
||||
|
||||
### ECC ciphers
|
||||
|
||||
`ecdh_ecdsa_null_sha`
|
||||
`ecdh_ecdsa_rc4_128_sha`
|
||||
`ecdh_ecdsa_3des_sha`
|
||||
`ecdh_ecdsa_aes_128_sha`
|
||||
`ecdh_ecdsa_aes_256_sha`
|
||||
`ecdhe_ecdsa_null_sha`
|
||||
`ecdhe_ecdsa_rc4_128_sha`
|
||||
`ecdhe_ecdsa_3des_sha`
|
||||
`ecdhe_ecdsa_aes_128_sha`
|
||||
`ecdhe_ecdsa_aes_256_sha`
|
||||
`ecdh_rsa_null_sha`
|
||||
`ecdh_rsa_128_sha`
|
||||
`ecdh_rsa_3des_sha`
|
||||
`ecdh_rsa_aes_128_sha`
|
||||
`ecdh_rsa_aes_256_sha`
|
||||
`ecdhe_rsa_null`
|
||||
`ecdhe_rsa_rc4_128_sha`
|
||||
`ecdhe_rsa_3des_sha`
|
||||
`ecdhe_rsa_aes_128_sha`
|
||||
`ecdhe_rsa_aes_256_sha`
|
||||
`ecdh_anon_null_sha`
|
||||
`ecdh_anon_rc4_128sha`
|
||||
`ecdh_anon_3des_sha`
|
||||
`ecdh_anon_aes_128_sha`
|
||||
`ecdh_anon_aes_256_sha`
|
||||
|
||||
### HMAC-SHA256 cipher suites
|
||||
|
||||
`rsa_null_sha_256`
|
||||
`rsa_aes_128_cbc_sha_256`
|
||||
`rsa_aes_256_cbc_sha_256`
|
||||
`dhe_rsa_aes_128_cbc_sha_256`
|
||||
`dhe_rsa_aes_256_cbc_sha_256`
|
||||
`ecdhe_ecdsa_aes_128_cbc_sha_256`
|
||||
`ecdhe_rsa_aes_128_cbc_sha_256`
|
||||
|
||||
### AES GCM cipher suites in RFC 5288 and RFC 5289
|
||||
|
||||
`rsa_aes_128_gcm_sha_256`
|
||||
`dhe_rsa_aes_128_gcm_sha_256`
|
||||
`dhe_dss_aes_128_gcm_sha_256`
|
||||
`ecdhe_ecdsa_aes_128_gcm_sha_256`
|
||||
`ecdh_ecdsa_aes_128_gcm_sha_256`
|
||||
`ecdhe_rsa_aes_128_gcm_sha_256`
|
||||
`ecdh_rsa_aes_128_gcm_sha_256`
|
||||
|
||||
### cipher suites using SHA384
|
||||
|
||||
`rsa_aes_256_gcm_sha_384`
|
||||
`dhe_rsa_aes_256_gcm_sha_384`
|
||||
`dhe_dss_aes_256_gcm_sha_384`
|
||||
`ecdhe_ecdsa_aes_256_sha_384`
|
||||
`ecdhe_rsa_aes_256_sha_384`
|
||||
`ecdhe_ecdsa_aes_256_gcm_sha_384`
|
||||
`ecdhe_rsa_aes_256_gcm_sha_384`
|
||||
|
||||
### chacha20-poly1305 cipher suites
|
||||
|
||||
`ecdhe_rsa_chacha20_poly1305_sha_256`
|
||||
`ecdhe_ecdsa_chacha20_poly1305_sha_256`
|
||||
`dhe_rsa_chacha20_poly1305_sha_256`
|
||||
|
||||
### TLS 1.3 cipher suites
|
||||
|
||||
`aes_128_gcm_sha_256`
|
||||
`aes_256_gcm_sha_384`
|
||||
`chacha20_poly1305_sha_256`
|
||||
|
||||
## GSKit
|
||||
|
||||
Ciphers are internally defined as [numeric
|
||||
codes](https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/apis/gsk_attribute_set_buffer.htm). libcurl
|
||||
maps them to the following case-insensitive names.
|
||||
|
||||
### SSL2 cipher suites (insecure: disabled by default)
|
||||
|
||||
`rc2-md5`
|
||||
`rc4-md5`
|
||||
`exp-rc2-md5`
|
||||
`exp-rc4-md5`
|
||||
`des-cbc-md5`
|
||||
`des-cbc3-md5`
|
||||
|
||||
### SSL3 cipher suites
|
||||
|
||||
`null-md5`
|
||||
`null-sha`
|
||||
`rc4-md5`
|
||||
`rc4-sha`
|
||||
`exp-rc2-cbc-md5`
|
||||
`exp-rc4-md5`
|
||||
`exp-des-cbc-sha`
|
||||
`des-cbc3-sha`
|
||||
|
||||
### TLS v1.0 cipher suites
|
||||
|
||||
`null-md5`
|
||||
`null-sha`
|
||||
`rc4-md5`
|
||||
`rc4-sha`
|
||||
`exp-rc2-cbc-md5`
|
||||
`exp-rc4-md5`
|
||||
`exp-des-cbc-sha`
|
||||
`des-cbc3-sha`
|
||||
`aes128-sha`
|
||||
`aes256-sha`
|
||||
|
||||
### TLS v1.1 cipher suites
|
||||
|
||||
`null-md5`
|
||||
`null-sha`
|
||||
`rc4-md5`
|
||||
`rc4-sha`
|
||||
`exp-des-cbc-sha`
|
||||
`des-cbc3-sha`
|
||||
`aes128-sha`
|
||||
`aes256-sha`
|
||||
|
||||
### TLS v1.2 cipher suites
|
||||
|
||||
`null-md5`
|
||||
`null-sha`
|
||||
`null-sha256`
|
||||
`rc4-md5`
|
||||
`rc4-sha`
|
||||
`des-cbc3-sha`
|
||||
`aes128-sha`
|
||||
`aes256-sha`
|
||||
`aes128-sha256`
|
||||
`aes256-sha256`
|
||||
`aes128-gcm-sha256`
|
||||
`aes256-gcm-sha384`
|
||||
|
||||
## WolfSSL
|
||||
|
||||
`RC4-SHA`,
|
||||
`RC4-MD5`,
|
||||
`DES-CBC3-SHA`,
|
||||
`AES128-SHA`,
|
||||
`AES256-SHA`,
|
||||
`NULL-SHA`,
|
||||
`NULL-SHA256`,
|
||||
`DHE-RSA-AES128-SHA`,
|
||||
`DHE-RSA-AES256-SHA`,
|
||||
`DHE-PSK-AES256-GCM-SHA384`,
|
||||
`DHE-PSK-AES128-GCM-SHA256`,
|
||||
`PSK-AES256-GCM-SHA384`,
|
||||
`PSK-AES128-GCM-SHA256`,
|
||||
`DHE-PSK-AES256-CBC-SHA384`,
|
||||
`DHE-PSK-AES128-CBC-SHA256`,
|
||||
`PSK-AES256-CBC-SHA384`,
|
||||
`PSK-AES128-CBC-SHA256`,
|
||||
`PSK-AES128-CBC-SHA`,
|
||||
`PSK-AES256-CBC-SHA`,
|
||||
`DHE-PSK-AES128-CCM`,
|
||||
`DHE-PSK-AES256-CCM`,
|
||||
`PSK-AES128-CCM`,
|
||||
`PSK-AES256-CCM`,
|
||||
`PSK-AES128-CCM-8`,
|
||||
`PSK-AES256-CCM-8`,
|
||||
`DHE-PSK-NULL-SHA384`,
|
||||
`DHE-PSK-NULL-SHA256`,
|
||||
`PSK-NULL-SHA384`,
|
||||
`PSK-NULL-SHA256`,
|
||||
`PSK-NULL-SHA`,
|
||||
`HC128-MD5`,
|
||||
`HC128-SHA`,
|
||||
`HC128-B2B256`,
|
||||
`AES128-B2B256`,
|
||||
`AES256-B2B256`,
|
||||
`RABBIT-SHA`,
|
||||
`NTRU-RC4-SHA`,
|
||||
`NTRU-DES-CBC3-SHA`,
|
||||
`NTRU-AES128-SHA`,
|
||||
`NTRU-AES256-SHA`,
|
||||
`AES128-CCM-8`,
|
||||
`AES256-CCM-8`,
|
||||
`ECDHE-ECDSA-AES128-CCM`,
|
||||
`ECDHE-ECDSA-AES128-CCM-8`,
|
||||
`ECDHE-ECDSA-AES256-CCM-8`,
|
||||
`ECDHE-RSA-AES128-SHA`,
|
||||
`ECDHE-RSA-AES256-SHA`,
|
||||
`ECDHE-ECDSA-AES128-SHA`,
|
||||
`ECDHE-ECDSA-AES256-SHA`,
|
||||
`ECDHE-RSA-RC4-SHA`,
|
||||
`ECDHE-RSA-DES-CBC3-SHA`,
|
||||
`ECDHE-ECDSA-RC4-SHA`,
|
||||
`ECDHE-ECDSA-DES-CBC3-SHA`,
|
||||
`AES128-SHA256`,
|
||||
`AES256-SHA256`,
|
||||
`DHE-RSA-AES128-SHA256`,
|
||||
`DHE-RSA-AES256-SHA256`,
|
||||
`ECDH-RSA-AES128-SHA`,
|
||||
`ECDH-RSA-AES256-SHA`,
|
||||
`ECDH-ECDSA-AES128-SHA`,
|
||||
`ECDH-ECDSA-AES256-SHA`,
|
||||
`ECDH-RSA-RC4-SHA`,
|
||||
`ECDH-RSA-DES-CBC3-SHA`,
|
||||
`ECDH-ECDSA-RC4-SHA`,
|
||||
`ECDH-ECDSA-DES-CBC3-SHA`,
|
||||
`AES128-GCM-SHA256`,
|
||||
`AES256-GCM-SHA384`,
|
||||
`DHE-RSA-AES128-GCM-SHA256`,
|
||||
`DHE-RSA-AES256-GCM-SHA384`,
|
||||
`ECDHE-RSA-AES128-GCM-SHA256`,
|
||||
`ECDHE-RSA-AES256-GCM-SHA384`,
|
||||
`ECDHE-ECDSA-AES128-GCM-SHA256`,
|
||||
`ECDHE-ECDSA-AES256-GCM-SHA384`,
|
||||
`ECDH-RSA-AES128-GCM-SHA256`,
|
||||
`ECDH-RSA-AES256-GCM-SHA384`,
|
||||
`ECDH-ECDSA-AES128-GCM-SHA256`,
|
||||
`ECDH-ECDSA-AES256-GCM-SHA384`,
|
||||
`CAMELLIA128-SHA`,
|
||||
`DHE-RSA-CAMELLIA128-SHA`,
|
||||
`CAMELLIA256-SHA`,
|
||||
`DHE-RSA-CAMELLIA256-SHA`,
|
||||
`CAMELLIA128-SHA256`,
|
||||
`DHE-RSA-CAMELLIA128-SHA256`,
|
||||
`CAMELLIA256-SHA256`,
|
||||
`DHE-RSA-CAMELLIA256-SHA256`,
|
||||
`ECDHE-RSA-AES128-SHA256`,
|
||||
`ECDHE-ECDSA-AES128-SHA256`,
|
||||
`ECDH-RSA-AES128-SHA256`,
|
||||
`ECDH-ECDSA-AES128-SHA256`,
|
||||
`ECDHE-RSA-AES256-SHA384`,
|
||||
`ECDHE-ECDSA-AES256-SHA384`,
|
||||
`ECDH-RSA-AES256-SHA384`,
|
||||
`ECDH-ECDSA-AES256-SHA384`,
|
||||
`ECDHE-RSA-CHACHA20-POLY1305`,
|
||||
`ECDHE-ECDSA-CHACHA20-POLY1305`,
|
||||
`DHE-RSA-CHACHA20-POLY1305`,
|
||||
`ECDHE-RSA-CHACHA20-POLY1305-OLD`,
|
||||
`ECDHE-ECDSA-CHACHA20-POLY1305-OLD`,
|
||||
`DHE-RSA-CHACHA20-POLY1305-OLD`,
|
||||
`ADH-AES128-SHA`,
|
||||
`QSH`,
|
||||
`RENEGOTIATION-INFO`,
|
||||
`IDEA-CBC-SHA`,
|
||||
`ECDHE-ECDSA-NULL-SHA`,
|
||||
`ECDHE-PSK-NULL-SHA256`,
|
||||
`ECDHE-PSK-AES128-CBC-SHA256`,
|
||||
`PSK-CHACHA20-POLY1305`,
|
||||
`ECDHE-PSK-CHACHA20-POLY1305`,
|
||||
`DHE-PSK-CHACHA20-POLY1305`,
|
||||
`EDH-RSA-DES-CBC3-SHA`,
|
||||
|
||||
## Schannel
|
||||
|
||||
Schannel allows the enabling and disabling of encryption algorithms, but not
|
||||
specific cipher suites. They are
|
||||
[defined](https://docs.microsoft.com/windows/desktop/SecCrypto/alg-id) by
|
||||
Microsoft.
|
||||
|
||||
There is also the case that the selected algorithm is not supported by the
|
||||
protocol or does not match the ciphers offered by the server during the SSL
|
||||
negotiation. In this case curl will return error
|
||||
`CURLE_SSL_CONNECT_ERROR (35) SEC_E_ALGORITHM_MISMATCH`
|
||||
and the request will fail.
|
||||
|
||||
`CALG_MD2`,
|
||||
`CALG_MD4`,
|
||||
`CALG_MD5`,
|
||||
`CALG_SHA`,
|
||||
`CALG_SHA1`,
|
||||
`CALG_MAC`,
|
||||
`CALG_RSA_SIGN`,
|
||||
`CALG_DSS_SIGN`,
|
||||
`CALG_NO_SIGN`,
|
||||
`CALG_RSA_KEYX`,
|
||||
`CALG_DES`,
|
||||
`CALG_3DES_112`,
|
||||
`CALG_3DES`,
|
||||
`CALG_DESX`,
|
||||
`CALG_RC2`,
|
||||
`CALG_RC4`,
|
||||
`CALG_SEAL`,
|
||||
`CALG_DH_SF`,
|
||||
`CALG_DH_EPHEM`,
|
||||
`CALG_AGREEDKEY_ANY`,
|
||||
`CALG_HUGHES_MD5`,
|
||||
`CALG_SKIPJACK`,
|
||||
`CALG_TEK`,
|
||||
`CALG_CYLINK_MEK`,
|
||||
`CALG_SSL3_SHAMD5`,
|
||||
`CALG_SSL3_MASTER`,
|
||||
`CALG_SCHANNEL_MASTER_HASH`,
|
||||
`CALG_SCHANNEL_MAC_KEY`,
|
||||
`CALG_SCHANNEL_ENC_KEY`,
|
||||
`CALG_PCT1_MASTER`,
|
||||
`CALG_SSL2_MASTER`,
|
||||
`CALG_TLS1_MASTER`,
|
||||
`CALG_RC5`,
|
||||
`CALG_HMAC`,
|
||||
`CALG_TLS1PRF`,
|
||||
`CALG_HASH_REPLACE_OWF`,
|
||||
`CALG_AES_128`,
|
||||
`CALG_AES_192`,
|
||||
`CALG_AES_256`,
|
||||
`CALG_AES`,
|
||||
`CALG_SHA_256`,
|
||||
`CALG_SHA_384`,
|
||||
`CALG_SHA_512`,
|
||||
`CALG_ECDH`,
|
||||
`CALG_ECMQV`,
|
||||
`CALG_ECDSA`,
|
||||
`CALG_ECDH_EPHEM`,
|
||||
|
||||
As of curl 7.77.0, you can also pass `SCH_USE_STRONG_CRYPTO` as a cipher name
|
||||
to [constrain the set of available ciphers as specified in the Schannel
|
||||
documentation](https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022).
|
||||
Note that the supported ciphers in this case follow the OS version, so if you
|
||||
are running an outdated OS you might still be supporting weak ciphers.
|
||||
|
||||
### TLS 1.3 cipher suites
|
||||
|
||||
(Note these ciphers are set with `CURLOPT_TLS13_CIPHERS` and `--tls13-ciphers`)
|
||||
|
||||
`TLS_AES_256_GCM_SHA384`
|
||||
`TLS_AES_128_GCM_SHA256`
|
||||
`TLS_CHACHA20_POLY1305_SHA256`
|
||||
`TLS_AES_128_CCM_8_SHA256`
|
||||
`TLS_AES_128_CCM_SHA256`
|
||||
|
||||
## BearSSL
|
||||
|
||||
BearSSL ciphers can be specified by either the OpenSSL name (`ECDHE-RSA-AES128-GCM-SHA256`) or the IANA name (`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`).
|
||||
|
||||
Since BearSSL 0.1:
|
||||
|
||||
`DES-CBC3-SHA`
|
||||
`AES128-SHA`
|
||||
`AES256-SHA`
|
||||
`AES128-SHA256`
|
||||
`AES256-SHA256`
|
||||
`AES128-GCM-SHA256`
|
||||
`AES256-GCM-SHA384`
|
||||
`ECDH-ECDSA-DES-CBC3-SHA`
|
||||
`ECDH-ECDSA-AES128-SHA`
|
||||
`ECDH-ECDSA-AES256-SHA`
|
||||
`ECDHE-ECDSA-DES-CBC3-SHA`
|
||||
`ECDHE-ECDSA-AES128-SHA`
|
||||
`ECDHE-ECDSA-AES256-SHA`
|
||||
`ECDH-RSA-DES-CBC3-SHA`
|
||||
`ECDH-RSA-AES128-SHA`
|
||||
`ECDH-RSA-AES256-SHA`
|
||||
`ECDHE-RSA-DES-CBC3-SHA`
|
||||
`ECDHE-RSA-AES128-SHA`
|
||||
`ECDHE-RSA-AES256-SHA`
|
||||
`ECDHE-ECDSA-AES128-SHA256`
|
||||
`ECDHE-ECDSA-AES256-SHA384`
|
||||
`ECDH-ECDSA-AES128-SHA256`
|
||||
`ECDH-ECDSA-AES256-SHA384`
|
||||
`ECDHE-RSA-AES128-SHA256`
|
||||
`ECDHE-RSA-AES256-SHA384`
|
||||
`ECDH-RSA-AES128-SHA256`
|
||||
`ECDH-RSA-AES256-SHA384`
|
||||
`ECDHE-ECDSA-AES128-GCM-SHA256`
|
||||
`ECDHE-ECDSA-AES256-GCM-SHA384`
|
||||
`ECDH-ECDSA-AES128-GCM-SHA256`
|
||||
`ECDH-ECDSA-AES256-GCM-SHA384`
|
||||
`ECDHE-RSA-AES128-GCM-SHA256`
|
||||
`ECDHE-RSA-AES256-GCM-SHA384`
|
||||
`ECDH-RSA-AES128-GCM-SHA256`
|
||||
`ECDH-RSA-AES256-GCM-SHA384`
|
||||
|
||||
Since BearSSL 0.2:
|
||||
|
||||
`ECDHE-RSA-CHACHA20-POLY1305`
|
||||
`ECDHE-ECDSA-CHACHA20-POLY1305`
|
||||
|
||||
Since BearSSL 0.6:
|
||||
|
||||
`AES128-CCM`
|
||||
`AES256-CCM`
|
||||
`AES128-CCM8`
|
||||
`AES256-CCM8`
|
||||
`ECDHE-ECDSA-AES128-CCM`
|
||||
`ECDHE-ECDSA-AES256-CCM`
|
||||
`ECDHE-ECDSA-AES128-CCM8`
|
||||
`ECDHE-ECDSA-AES256-CCM8`
|
||||
@ -0,0 +1,32 @@
|
||||
Contributor Code of Conduct
|
||||
===========================
|
||||
|
||||
As contributors and maintainers of this project, we pledge to respect all
|
||||
people who contribute through reporting issues, posting feature requests,
|
||||
updating documentation, submitting pull requests or patches, and other
|
||||
activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, or religion.
|
||||
|
||||
Examples of unacceptable behavior by participants include the use of sexual
|
||||
language or imagery, derogatory comments or personal attacks, trolling, public
|
||||
or private harassment, insults, or other unprofessional conduct.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct. Project maintainers who do not
|
||||
follow the Code of Conduct may be removed from the project team.
|
||||
|
||||
This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by opening an issue or contacting one or more of the project
|
||||
maintainers.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor
|
||||
Covenant](https://contributor-covenant.org/), version 1.1.0, available at
|
||||
[https://contributor-covenant.org/version/1/1/0/](https://contributor-covenant.org/version/1/1/0/)
|
||||
@ -0,0 +1,168 @@
|
||||
# How to do code reviews for curl
|
||||
|
||||
Anyone and everyone is encouraged and welcome to review code submissions in
|
||||
curl. This is a guide on what to check for and how to perform a successful
|
||||
code review.
|
||||
|
||||
## All submissions should get reviewed
|
||||
|
||||
All pull requests and patches submitted to the project should be reviewed by
|
||||
at least one experienced curl maintainer before that code is accepted and
|
||||
merged.
|
||||
|
||||
## Let the tools and tests take the first rounds
|
||||
|
||||
On initial pull requests, let the tools and tests do their job first and then
|
||||
start out by helping the submitter understand the test failures and tool
|
||||
alerts.
|
||||
|
||||
## How to provide feedback to author
|
||||
|
||||
Be nice. Ask questions. Provide examples or suggestions of improvements.
|
||||
Assume the best intentions. Remember language barriers.
|
||||
|
||||
All first-time contributors can become regulars. Let's help them go there.
|
||||
|
||||
## Is this a change we want?
|
||||
|
||||
If this is not a change that seems to be aligned with the project's path
|
||||
forward and as such cannot be accepted, inform the author about this sooner
|
||||
rather than later. Do it gently and explain why and possibly what could be
|
||||
done to make it more acceptable.
|
||||
|
||||
## API/ABI stability or changed behavior
|
||||
|
||||
Changing the API and the ABI may be fine in a change but it needs to be done
|
||||
deliberately and carefully. If not, a reviewer must help the author to realize
|
||||
the mistake.
|
||||
|
||||
curl and libcurl are similarly strict on not modifying existing behavior. API
|
||||
and ABI stability is not enough, the behavior should also remain intact as far
|
||||
as possible.
|
||||
|
||||
## Code style
|
||||
|
||||
Most code style nits are detected by checksrc but not all. Only leave remarks
|
||||
on style deviation once checksrc does not find anymore.
|
||||
|
||||
Minor nits from fresh submitters can also be handled by the maintainer when
|
||||
merging, in case it seems like the submitter is not clear on what to do. We
|
||||
want to make the process fun and exciting for new contributors.
|
||||
|
||||
## Encourage consistency
|
||||
|
||||
Make sure new code is written in a similar style as existing code. Naming,
|
||||
logic, conditions, etc.
|
||||
|
||||
## Are pointers always non-NULL?
|
||||
|
||||
If a function or code rely on pointers being non-NULL, take an extra look if
|
||||
that seems to be a fair assessment.
|
||||
|
||||
## Asserts
|
||||
|
||||
Conditions that should never be false can be verified with `DEBUGASSERT()`
|
||||
calls to get caught in tests and debugging easier, while not having an impact
|
||||
on final or release builds.
|
||||
|
||||
## Memory allocation
|
||||
|
||||
Can the mallocs be avoided? Do not introduce mallocs in any hot paths. If
|
||||
there are (new) mallocs, can they be combined into fewer calls?
|
||||
|
||||
Are all allocations handled in error paths to avoid leaks and crashes?
|
||||
|
||||
## Thread-safety
|
||||
|
||||
We do not like static variables as they break thread-safety and prevent
|
||||
functions from being reentrant.
|
||||
|
||||
## Should features be `#ifdef`ed?
|
||||
|
||||
Features and functionality may not be present everywhere and should therefore
|
||||
be `#ifdef`ed. Additionally, some features should be possible to switch on/off
|
||||
in the build.
|
||||
|
||||
Write `#ifdef`s to be as little of a "maze" as possible.
|
||||
|
||||
## Does it look portable enough?
|
||||
|
||||
curl runs "everywhere". Does the code take a reasonable stance and enough
|
||||
precautions to be possible to build and run on most platforms?
|
||||
|
||||
Remember that we live by C89 restrictions.
|
||||
|
||||
## Tests and testability
|
||||
|
||||
New features should be added in conjunction with one or more test cases.
|
||||
Ideally, functions should also be written so that unit tests can be done to
|
||||
test individual functions.
|
||||
|
||||
## Documentation
|
||||
|
||||
New features or changes to existing functionality **must** be accompanied by
|
||||
updated documentation. Submitting that in a separate follow-up pull request is
|
||||
not OK. A code review must also verify that the submitted documentation update
|
||||
matches the code submission.
|
||||
|
||||
English is not everyone's first language, be mindful of this and help the
|
||||
submitter improve the text if it needs a rewrite to read better.
|
||||
|
||||
## Code should not be hard to understand
|
||||
|
||||
Source code should be written to maximize readability and be easy to
|
||||
understand.
|
||||
|
||||
## Functions should not be large
|
||||
|
||||
A single function should never be large as that makes it hard to follow and
|
||||
understand all the exit points and state changes. Some existing functions in
|
||||
curl certainly violate this ground rule but when reviewing new code we should
|
||||
propose splitting into smaller functions.
|
||||
|
||||
## Duplication is evil
|
||||
|
||||
Anything that looks like duplicated code is a red flag. Anything that seems to
|
||||
introduce code that we *should* already have or provide needs a closer check.
|
||||
|
||||
## Sensitive data
|
||||
|
||||
When credentials are involved, take an extra look at what happens with this
|
||||
data. Where it comes from and where it goes.
|
||||
|
||||
## Variable types differ
|
||||
|
||||
`size_t` is not a fixed size. `time_t` can be signed or unsigned and have
|
||||
different sizes. Relying on variable sizes is a red flag.
|
||||
|
||||
Also remember that endianness and >= 32 bit accesses to unaligned addresses
|
||||
are problematic areas.
|
||||
|
||||
## Integer overflows
|
||||
|
||||
Be careful about integer overflows. Some variable types can be either 32 bit
|
||||
or 64 bit. Integer overflows must be detected and acted on *before* they
|
||||
happen.
|
||||
|
||||
## Dangerous use of functions
|
||||
|
||||
Maybe use of `realloc()` should rather use the dynbuf functions?
|
||||
|
||||
Do not allow new code that grows buffers without using dynbuf.
|
||||
|
||||
Use of C functions that rely on a terminating zero must only be used on data
|
||||
that really do have a null-terminating zero.
|
||||
|
||||
## Dangerous "data styles"
|
||||
|
||||
Make extra precautions and verify that memory buffers that need a terminating
|
||||
zero always have exactly that. Buffers *without* a null-terminator must not be
|
||||
used as input to string functions.
|
||||
|
||||
# Commit messages
|
||||
|
||||
Tightly coupled with a code review is making sure that the commit message is
|
||||
good. It is the responsibility of the person who merges the code to make sure
|
||||
that the commit message follows our standard (detailed in the
|
||||
[CONTRIBUTE](CONTRIBUTE.md) document). This includes making sure the PR
|
||||
identifies related issues and giving credit to reporters and helpers.
|
||||
@ -0,0 +1,310 @@
|
||||
# curl C code style
|
||||
|
||||
Source code that has a common style is easier to read than code that uses
|
||||
different styles in different places. It helps making the code feel like one
|
||||
single code base. Easy-to-read is an important property of code and helps
|
||||
making it easier to review when new things are added and it helps debugging
|
||||
code when developers are trying to figure out why things go wrong. A unified
|
||||
style is more important than individual contributors having their own personal
|
||||
tastes satisfied.
|
||||
|
||||
Our C code has a few style rules. Most of them are verified and upheld by the
|
||||
`scripts/checksrc.pl` script. Invoked with `make checksrc` or even by default
|
||||
by the build system when built after `./configure --enable-debug` has been
|
||||
used.
|
||||
|
||||
It is normally not a problem for anyone to follow the guidelines, as you just
|
||||
need to copy the style already used in the source code and there are no
|
||||
particularly unusual rules in our set of rules.
|
||||
|
||||
We also work hard on writing code that are warning-free on all the major
|
||||
platforms and in general on as many platforms as possible. Code that obviously
|
||||
will cause warnings will not be accepted as-is.
|
||||
|
||||
## Naming
|
||||
|
||||
Try using a non-confusing naming scheme for your new functions and variable
|
||||
names. It does not necessarily have to mean that you should use the same as in
|
||||
other places of the code, just that the names should be logical,
|
||||
understandable and be named according to what they are used for. File-local
|
||||
functions should be made static. We like lower case names.
|
||||
|
||||
See the [INTERNALS](https://curl.se/dev/internals.html#symbols) document on
|
||||
how we name non-exported library-global symbols.
|
||||
|
||||
## Indenting
|
||||
|
||||
We use only spaces for indentation, never TABs. We use two spaces for each new
|
||||
open brace.
|
||||
|
||||
```c
|
||||
if(something_is_true) {
|
||||
while(second_statement == fine) {
|
||||
moo();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Comments
|
||||
|
||||
Since we write C89 code, **//** comments are not allowed. They were not
|
||||
introduced in the C standard until C99. We use only __/* comments */__.
|
||||
|
||||
```c
|
||||
/* this is a comment */
|
||||
```
|
||||
|
||||
## Long lines
|
||||
|
||||
Source code in curl may never be wider than 79 columns and there are two
|
||||
reasons for maintaining this even in the modern era of large and high
|
||||
resolution screens:
|
||||
|
||||
1. Narrower columns are easier to read than wide ones. There's a reason
|
||||
newspapers have used columns for decades or centuries.
|
||||
|
||||
2. Narrower columns allow developers to easier show multiple pieces of code
|
||||
next to each other in different windows. I often have two or three source
|
||||
code windows next to each other on the same screen - as well as multiple
|
||||
terminal and debugging windows.
|
||||
|
||||
## Braces
|
||||
|
||||
In if/while/do/for expressions, we write the open brace on the same line as
|
||||
the keyword and we then set the closing brace on the same indentation level as
|
||||
the initial keyword. Like this:
|
||||
|
||||
```c
|
||||
if(age < 40) {
|
||||
/* clearly a youngster */
|
||||
}
|
||||
```
|
||||
|
||||
You may omit the braces if they would contain only a one-line statement:
|
||||
|
||||
```c
|
||||
if(!x)
|
||||
continue;
|
||||
```
|
||||
|
||||
For functions the opening brace should be on a separate line:
|
||||
|
||||
```c
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
return 1;
|
||||
}
|
||||
```
|
||||
|
||||
## 'else' on the following line
|
||||
|
||||
When adding an **else** clause to a conditional expression using braces, we
|
||||
add it on a new line after the closing brace. Like this:
|
||||
|
||||
```c
|
||||
if(age < 40) {
|
||||
/* clearly a youngster */
|
||||
}
|
||||
else {
|
||||
/* probably grumpy */
|
||||
}
|
||||
```
|
||||
|
||||
## No space before parentheses
|
||||
|
||||
When writing expressions using if/while/do/for, there shall be no space
|
||||
between the keyword and the open parenthesis. Like this:
|
||||
|
||||
```c
|
||||
while(1) {
|
||||
/* loop forever */
|
||||
}
|
||||
```
|
||||
|
||||
## Use boolean conditions
|
||||
|
||||
Rather than test a conditional value such as a bool against TRUE or FALSE, a
|
||||
pointer against NULL or != NULL and an int against zero or not zero in
|
||||
if/while conditions we prefer:
|
||||
|
||||
```c
|
||||
result = do_something();
|
||||
if(!result) {
|
||||
/* something went wrong */
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
## No assignments in conditions
|
||||
|
||||
To increase readability and reduce complexity of conditionals, we avoid
|
||||
assigning variables within if/while conditions. We frown upon this style:
|
||||
|
||||
```c
|
||||
if((ptr = malloc(100)) == NULL)
|
||||
return NULL;
|
||||
```
|
||||
|
||||
and instead we encourage the above version to be spelled out more clearly:
|
||||
|
||||
```c
|
||||
ptr = malloc(100);
|
||||
if(!ptr)
|
||||
return NULL;
|
||||
```
|
||||
|
||||
## New block on a new line
|
||||
|
||||
We never write multiple statements on the same source line, even for short
|
||||
if() conditions.
|
||||
|
||||
```c
|
||||
if(a)
|
||||
return TRUE;
|
||||
else if(b)
|
||||
return FALSE;
|
||||
```
|
||||
|
||||
and NEVER:
|
||||
|
||||
```c
|
||||
if(a) return TRUE;
|
||||
else if(b) return FALSE;
|
||||
```
|
||||
|
||||
## Space around operators
|
||||
|
||||
Please use spaces on both sides of operators in C expressions. Postfix **(),
|
||||
[], ->, ., ++, --** and Unary **+, -, !, ~, &** operators excluded they should
|
||||
have no space.
|
||||
|
||||
Examples:
|
||||
|
||||
```c
|
||||
bla = func();
|
||||
who = name[0];
|
||||
age += 1;
|
||||
true = !false;
|
||||
size += -2 + 3 * (a + b);
|
||||
ptr->member = a++;
|
||||
struct.field = b--;
|
||||
ptr = &address;
|
||||
contents = *pointer;
|
||||
complement = ~bits;
|
||||
empty = (!*string) ? TRUE : FALSE;
|
||||
```
|
||||
|
||||
## No parentheses for return values
|
||||
|
||||
We use the 'return' statement without extra parentheses around the value:
|
||||
|
||||
```c
|
||||
int works(void)
|
||||
{
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
|
||||
## Parentheses for sizeof arguments
|
||||
|
||||
When using the sizeof operator in code, we prefer it to be written with
|
||||
parentheses around its argument:
|
||||
|
||||
```c
|
||||
int size = sizeof(int);
|
||||
```
|
||||
|
||||
## Column alignment
|
||||
|
||||
Some statements cannot be completed on a single line because the line would be
|
||||
too long, the statement too hard to read, or due to other style guidelines
|
||||
above. In such a case the statement will span multiple lines.
|
||||
|
||||
If a continuation line is part of an expression or sub-expression then you
|
||||
should align on the appropriate column so that it's easy to tell what part of
|
||||
the statement it is. Operators should not start continuation lines. In other
|
||||
cases follow the 2-space indent guideline. Here are some examples from
|
||||
libcurl:
|
||||
|
||||
```c
|
||||
if(Curl_pipeline_wanted(handle->multi, CURLPIPE_HTTP1) &&
|
||||
(handle->set.httpversion != CURL_HTTP_VERSION_1_0) &&
|
||||
(handle->set.httpreq == HTTPREQ_GET ||
|
||||
handle->set.httpreq == HTTPREQ_HEAD))
|
||||
/* did not ask for HTTP/1.0 and a GET or HEAD */
|
||||
return TRUE;
|
||||
```
|
||||
|
||||
If no parenthesis, use the default indent:
|
||||
|
||||
```c
|
||||
data->set.http_disable_hostname_check_before_authentication =
|
||||
(0 != va_arg(param, long)) ? TRUE : FALSE;
|
||||
```
|
||||
|
||||
Function invoke with an open parenthesis:
|
||||
|
||||
```c
|
||||
if(option) {
|
||||
result = parse_login_details(option, strlen(option),
|
||||
(userp ? &user : NULL),
|
||||
(passwdp ? &passwd : NULL),
|
||||
NULL);
|
||||
}
|
||||
```
|
||||
|
||||
Align with the "current open" parenthesis:
|
||||
|
||||
```c
|
||||
DEBUGF(infof(data, "Curl_pp_readresp_ %d bytes of trailing "
|
||||
"server response left\n",
|
||||
(int)clipamount));
|
||||
```
|
||||
|
||||
## Platform dependent code
|
||||
|
||||
Use **#ifdef HAVE_FEATURE** to do conditional code. We avoid checking for
|
||||
particular operating systems or hardware in the #ifdef lines. The HAVE_FEATURE
|
||||
shall be generated by the configure script for unix-like systems and they are
|
||||
hard-coded in the `config-[system].h` files for the others.
|
||||
|
||||
We also encourage use of macros/functions that possibly are empty or defined
|
||||
to constants when libcurl is built without that feature, to make the code
|
||||
seamless. Like this example where the **magic()** function works differently
|
||||
depending on a build-time conditional:
|
||||
|
||||
```c
|
||||
#ifdef HAVE_MAGIC
|
||||
void magic(int a)
|
||||
{
|
||||
return a + 2;
|
||||
}
|
||||
#else
|
||||
#define magic(x) 1
|
||||
#endif
|
||||
|
||||
int content = magic(3);
|
||||
```
|
||||
|
||||
## No typedefed structs
|
||||
|
||||
Use structs by all means, but do not typedef them. Use the `struct name` way
|
||||
of identifying them:
|
||||
|
||||
```c
|
||||
struct something {
|
||||
void *valid;
|
||||
size_t way_to_write;
|
||||
};
|
||||
struct something instance;
|
||||
```
|
||||
|
||||
**Not okay**:
|
||||
|
||||
```c
|
||||
typedef struct {
|
||||
void *wrong;
|
||||
size_t way_to_write;
|
||||
} something;
|
||||
something instance;
|
||||
```
|
||||
@ -0,0 +1,127 @@
|
||||
# curl connection filters
|
||||
|
||||
Connection filters is a design in the internals of curl, not visible in its public API. They were added
|
||||
in curl v7.xx.x. This document describes the concepts, its high level implementation and the motivations.
|
||||
|
||||
## Filters
|
||||
|
||||
A "connection filter" is a piece of code that is responsible for handling a range of operations
|
||||
of curl's connections: reading, writing, waiting on external events, connecting and closing down - to name the most important ones.
|
||||
|
||||
The most important feat of connection filters is that they can be stacked on top of each other (or "chained" if you prefer that metaphor). In the common scenario that you want to retrieve a `https:` url with curl, you need 2 basic things to send the request and get the response: a TCP connection, represented by a `socket` and a SSL instance en- and decrypt over that socket. You write your request to the SSL instance, which encrypts and writes that data to the socket, which then sends the bytes over the network.
|
||||
|
||||
With connection filters, curl's internal setup will look something like this (cf for connection filter):
|
||||
|
||||
```
|
||||
Curl_easy *data connectdata *conn cf-ssl cf-socket
|
||||
+----------------+ +-----------------+ +-------+ +--------+
|
||||
|https://curl.se/|----> | properties |----> | keys |---> | socket |--> OS --> network
|
||||
+----------------+ +-----------------+ +-------+ +--------+
|
||||
|
||||
Curl_write(data, buffer)
|
||||
--> Curl_cfilter_write(data, data->conn, buffer)
|
||||
---> conn->filter->write(conn->filter, data, buffer)
|
||||
```
|
||||
|
||||
While connection filters all do different things, they look the same from the "outside". The code in `data` and `conn` does not really know **which** filters are installed. `conn` just writes into the first filter, whatever that is.
|
||||
|
||||
Same is true for filters. Each filter has a pointer to the `next` filter. When SSL has encrypted the data, it does not write to a socket, it writes to the next filter. If that is indeed a socket, or a file, or a HTTP/2 connection is of no concern to the SSL filter.
|
||||
|
||||
And this allows the stacking, as in:
|
||||
|
||||
```
|
||||
Direct:
|
||||
http://localhost/ conn -> cf-socket
|
||||
https://curl.se/ conn -> cf-ssl -> cf-socket
|
||||
Via http proxy tunnel:
|
||||
http://localhost/ conn -> cf-http-proxy -> cf-socket
|
||||
https://curl.se/ conn -> cf-ssl -> cf-http-proxy -> cf-socket
|
||||
Via https proxy tunnel:
|
||||
http://localhost/ conn -> cf-http-proxy -> cf-ssl -> cf-socket
|
||||
https://curl.se/ conn -> cf-ssl -> cf-http-proxy -> cf-ssl -> cf-socket
|
||||
Via http proxy tunnel via SOCKS proxy:
|
||||
http://localhost/ conn -> cf-http-proxy -> cf-socks -> cf-socket
|
||||
```
|
||||
|
||||
### Connecting/Closing
|
||||
|
||||
Before `Curl_easy` can send the request, the connection needs to be established. This means that all connection filters have done, whatever they need to do: waiting for the socket to be connected, doing the TLS handshake, performing the HTTP tunnel request, etc. This has to be done in reverse order: the last filter has to do its connect first, then the one above can start, etc.
|
||||
|
||||
Each filter does in principle the following:
|
||||
|
||||
```
|
||||
static CURLcode
|
||||
myfilter_cf_connect(struct Curl_cfilter *cf,
|
||||
struct Curl_easy *data,
|
||||
bool *done)
|
||||
{
|
||||
CURLcode result;
|
||||
|
||||
if(cf->connected) { /* we and all below are done */
|
||||
*done = TRUE;
|
||||
return CURLE_OK;
|
||||
}
|
||||
/* Let the filters below connect */
|
||||
result = cf->next->cft->connect(cf->next, data, blocking, done);
|
||||
if(result || !*done)
|
||||
return result; /* below errored/not finished yet */
|
||||
|
||||
/* MYFILTER CONNECT THINGS */ /* below connected, do out thing */
|
||||
*done = cf->connected = TRUE; /* done, remember, return */
|
||||
return CURLE_OK;
|
||||
}
|
||||
```
|
||||
|
||||
Closing a connection then works similar. The `conn` tells the first filter to close. Contrary to connecting,
|
||||
the filter does its own things first, before telling the next filter to close.
|
||||
|
||||
### Efficiency
|
||||
|
||||
There are two things curl is concerned about: efficient memory use and fast transfers.
|
||||
|
||||
The memory footprint of a filter is relatively small:
|
||||
|
||||
```
|
||||
struct Curl_cfilter {
|
||||
const struct Curl_cftype *cft; /* the type providing implementation */
|
||||
struct Curl_cfilter *next; /* next filter in chain */
|
||||
void *ctx; /* filter type specific settings */
|
||||
struct connectdata *conn; /* the connection this filter belongs to */
|
||||
int sockindex; /* TODO: like to get rid off this */
|
||||
BIT(connected); /* != 0 iff this filter is connected */
|
||||
};
|
||||
```
|
||||
The filter type `cft` is a singleton, one static struct for each type of filter. The `ctx` is where a filter will hold its specific data. That varies by filter type. A http-proxy filter will keep the ongoing state of the CONNECT here, but free it after its has been established. The SSL filter will keep the `SSL*` (if OpenSSL is used) here until the connection is closed. So, this varies.
|
||||
|
||||
`conn` is a reference to the connection this filter belongs to, so nothing extra besides the pointer itself.
|
||||
|
||||
Several things, that before were kept in `struct connectdata`, will now go into the `filter->ctx` *when needed*. So, the memory footprint for connections that do *not* use a http proxy, or socks, or https will be lower.
|
||||
|
||||
As to transfer efficiency, writing and reading through a filter comes at near zero cost *if the filter does not transform the data*. A http proxy or socks filter, once it is connected, will just pass the calls through. Those filters implementations will look like this:
|
||||
|
||||
```
|
||||
ssize_t Curl_cf_def_send(struct Curl_cfilter *cf, struct Curl_easy *data,
|
||||
const void *buf, size_t len, CURLcode *err)
|
||||
{
|
||||
return cf->next->cft->do_send(cf->next, data, buf, len, err);
|
||||
}
|
||||
```
|
||||
The `recv` implementation is equivalent.
|
||||
|
||||
## Filter Types
|
||||
|
||||
The (currently) existing filter types are: SOCKET, SOCKET-ACCEPT, SSL, HTTP-PROXY and SOCKS-PROXY. Vital to establishing and read/writing a connection. But filters are also a good way to implement tasks for *managing* a connection:
|
||||
|
||||
* **Statistics**: a filter that counts the number of bytes sent/received. Place one in front of SOCKET and one higher up and get the number of raw and "easy" bytes transferred. They may track the speed as well, or number of partial writes, etc.
|
||||
* **Timeout**: enforce timeouts, e.g. fail if a connection cannot be established in a certain amount of time.
|
||||
* **Progress**: report progress on a connection.
|
||||
* **Pacing**: limit read/write rates.
|
||||
* **Testing**: simulate network condition or failures.
|
||||
|
||||
As you see, filters are a good way to add functionality to curl's internal handling of transfers without impact on other code.
|
||||
|
||||
## Easy Filters?
|
||||
|
||||
Some things that curl needs to manage are not directly tied to a specific connection but the property of the `Curl_easy` handle, e.g. a particular transfer. When using HTTP/2 or HTTP/3, many transfers can use the same connection. If one wants to monitor of the transfer itself or restricting its speed alone, a connection filter is not the right place to do this.
|
||||
|
||||
So we might add "easy filters" one day. Who knows?
|
||||
@ -0,0 +1,319 @@
|
||||
# Contributing to the curl project
|
||||
|
||||
This document is intended to offer guidelines on how to best contribute to the
|
||||
curl project. This concerns new features as well as corrections to existing
|
||||
flaws or bugs.
|
||||
|
||||
## Join the Community
|
||||
|
||||
Skip over to [https://curl.se/mail/](https://curl.se/mail/) and join
|
||||
the appropriate mailing list(s). Read up on details before you post
|
||||
questions. Read this file before you start sending patches. We prefer
|
||||
questions sent to and discussions being held on the mailing list(s), not sent
|
||||
to individuals.
|
||||
|
||||
Before posting to one of the curl mailing lists, please read up on the
|
||||
[mailing list etiquette](https://curl.se/mail/etiquette.html).
|
||||
|
||||
We also hang out on IRC in #curl on libera.chat
|
||||
|
||||
If you are at all interested in the code side of things, consider clicking
|
||||
'watch' on the [curl repo on GitHub](https://github.com/curl/curl) to be
|
||||
notified of pull requests and new issues posted there.
|
||||
|
||||
## License and copyright
|
||||
|
||||
When contributing with code, you agree to put your changes and new code under
|
||||
the same license curl and libcurl is already using unless stated and agreed
|
||||
otherwise.
|
||||
|
||||
If you add a larger piece of code, you can opt to make that file or set of
|
||||
files to use a different license as long as they do not enforce any changes to
|
||||
the rest of the package and they make sense. Such "separate parts" can not be
|
||||
GPL licensed (as we do not want copyleft to affect users of libcurl) but they
|
||||
must use "GPL compatible" licenses (as we want to allow users to use libcurl
|
||||
properly in GPL licensed environments).
|
||||
|
||||
When changing existing source code, you do not alter the copyright of the
|
||||
original file(s). The copyright will still be owned by the original creator(s)
|
||||
or those who have been assigned copyright by the original author(s).
|
||||
|
||||
By submitting a patch to the curl project, you are assumed to have the right
|
||||
to the code and to be allowed by your employer or whatever to hand over that
|
||||
patch/code to us. We will credit you for your changes as far as possible, to
|
||||
give credit but also to keep a trace back to who made what changes. Please
|
||||
always provide us with your full real name when contributing,
|
||||
|
||||
## What To Read
|
||||
|
||||
Source code, the man pages, the [INTERNALS
|
||||
document](https://curl.se/dev/internals.html),
|
||||
[TODO](https://curl.se/docs/todo.html),
|
||||
[KNOWN_BUGS](https://curl.se/docs/knownbugs.html) and the [most recent
|
||||
changes](https://curl.se/dev/sourceactivity.html) in git. Just lurking on
|
||||
the [curl-library mailing
|
||||
list](https://curl.se/mail/list.cgi?list=curl-library) will give you a
|
||||
lot of insights on what's going on right now. Asking there is a good idea too.
|
||||
|
||||
## Write a good patch
|
||||
|
||||
### Follow code style
|
||||
|
||||
When writing C code, follow the
|
||||
[CODE_STYLE](https://curl.se/dev/code-style.html) already established in
|
||||
the project. Consistent style makes code easier to read and mistakes less
|
||||
likely to happen. Run `make checksrc` before you submit anything, to make sure
|
||||
you follow the basic style. That script does not verify everything, but if it
|
||||
complains you know you have work to do.
|
||||
|
||||
### Non-clobbering All Over
|
||||
|
||||
When you write new functionality or fix bugs, it is important that you do not
|
||||
fiddle all over the source files and functions. Remember that it is likely
|
||||
that other people have done changes in the same source files as you have and
|
||||
possibly even in the same functions. If you bring completely new
|
||||
functionality, try writing it in a new source file. If you fix bugs, try to
|
||||
fix one bug at a time and send them as separate patches.
|
||||
|
||||
### Write Separate Changes
|
||||
|
||||
It is annoying when you get a huge patch from someone that is said to fix 511
|
||||
odd problems, but discussions and opinions do not agree with 510 of them - or
|
||||
509 of them were already fixed in a different way. Then the person merging
|
||||
this change needs to extract the single interesting patch from somewhere
|
||||
within the huge pile of source, and that creates a lot of extra work.
|
||||
|
||||
Preferably, each fix that corrects a problem should be in its own patch/commit
|
||||
with its own description/commit message stating exactly what they correct so
|
||||
that all changes can be selectively applied by the maintainer or other
|
||||
interested parties.
|
||||
|
||||
Also, separate changes enable bisecting much better for tracking problems
|
||||
and regression in the future.
|
||||
|
||||
### Patch Against Recent Sources
|
||||
|
||||
Please try to get the latest available sources to make your patches against.
|
||||
It makes the lives of the developers so much easier. The best is if you get
|
||||
the most up-to-date sources from the git repository, but the latest release
|
||||
archive is quite OK as well.
|
||||
|
||||
### Documentation
|
||||
|
||||
Writing docs is dead boring and one of the big problems with many open source
|
||||
projects. But someone's gotta do it. It makes things a lot easier if you
|
||||
submit a small description of your fix or your new features with every
|
||||
contribution so that it can be swiftly added to the package documentation.
|
||||
|
||||
The documentation is always made in man pages (nroff formatted) or plain
|
||||
ASCII files. All HTML files on the website and in the release archives are
|
||||
generated from the nroff/ASCII versions.
|
||||
|
||||
### Test Cases
|
||||
|
||||
Since the introduction of the test suite, we can quickly verify that the main
|
||||
features are working as they are supposed to. To maintain this situation and
|
||||
improve it, all new features and functions that are added need to be tested
|
||||
in the test suite. Every feature that is added should get at least one valid
|
||||
test case that verifies that it works as documented. If every submitter also
|
||||
posts a few test cases, it will not end up as a heavy burden on a single person!
|
||||
|
||||
If you do not have test cases or perhaps you have done something that is hard
|
||||
to write tests for, do explain exactly how you have otherwise tested and
|
||||
verified your changes.
|
||||
|
||||
## Submit Your Changes
|
||||
|
||||
### How to get your changes into the main sources
|
||||
|
||||
Ideally you file a [pull request on
|
||||
GitHub](https://github.com/curl/curl/pulls), but you can also send your plain
|
||||
patch to [the curl-library mailing
|
||||
list](https://curl.se/mail/list.cgi?list=curl-library).
|
||||
|
||||
If you opt to post a patch on the mailing list, chances are someone will
|
||||
convert it into a pull request for you, to have the CI jobs verify it proper
|
||||
before it can be merged. Be prepared that some feedback on the proposed change
|
||||
might then come on GitHub.
|
||||
|
||||
Your change will be reviewed and discussed and you will be expected to correct
|
||||
flaws pointed out and update accordingly, or the change risks stalling and
|
||||
eventually just getting deleted without action. As a submitter of a change,
|
||||
you are the owner of that change until it has been merged.
|
||||
|
||||
Respond on the list or on GitHub about the change and answer questions and/or
|
||||
fix nits/flaws. This is important. We will take lack of replies as a sign that
|
||||
you are not anxious to get your patch accepted and we tend to simply drop such
|
||||
changes.
|
||||
|
||||
### About pull requests
|
||||
|
||||
With GitHub it is easy to send a [pull
|
||||
request](https://github.com/curl/curl/pulls) to the curl project to have
|
||||
changes merged.
|
||||
|
||||
We strongly prefer pull requests to mailed patches, as it makes it a proper
|
||||
git commit that is easy to merge and they are easy to track and not that easy
|
||||
to lose in the flood of many emails, like they sometimes do on the mailing
|
||||
lists.
|
||||
|
||||
Every pull request submitted will automatically be tested in several different
|
||||
ways. [See the CI document for more
|
||||
information](https://github.com/curl/curl/blob/master/tests/CI.md).
|
||||
|
||||
Sometimes the tests fail due to a dependency service temporarily being offline
|
||||
or otherwise unavailable, e.g. package downloads. In this case you can just
|
||||
try to update your pull requests to rerun the tests later as described below.
|
||||
|
||||
You can update your pull requests by pushing new commits or force-pushing
|
||||
changes to existing commits. Force-pushing an amended commit without any
|
||||
actual content changed also allows you to retrigger the tests for that commit.
|
||||
|
||||
When you adjust your pull requests after review, consider squashing the
|
||||
commits so that we can review the full updated version more easily.
|
||||
|
||||
A pull request sent to the project might get labeled `needs-votes` by a
|
||||
project maintainer. This label means that in addition to meeting all other
|
||||
checks and qualifications this pull request must also receive more "votes" of
|
||||
user support. More signs that people want this to happen. It could be in the
|
||||
form of messages saying so, or thumbs-up reactions on GitHub.
|
||||
|
||||
### Making quality changes
|
||||
|
||||
Make the patch against as recent source versions as possible.
|
||||
|
||||
If you have followed the tips in this document and your patch still has not
|
||||
been incorporated or responded to after some weeks, consider resubmitting it
|
||||
to the list or better yet: change it to a pull request.
|
||||
|
||||
### Commit messages
|
||||
|
||||
A short guide to how to write git commit messages in the curl project.
|
||||
|
||||
---- start ----
|
||||
[area]: [short line describing the main effect]
|
||||
-- empty line --
|
||||
[full description, no wider than 72 columns that describes as much as
|
||||
possible as to why this change is made, and possibly what things
|
||||
it fixes and everything else that is related, with unwieldy URLs replaced
|
||||
with references like [0], [1], etc.]
|
||||
-- empty line --
|
||||
[[0] URL - Reference to a URL in the description, almost like Markdown;
|
||||
the last numbered reference is followed by an -- empty line -- ]
|
||||
[Follow-up to {shorthash} - if this fixes or continues a previous commit;
|
||||
add a Ref: that commit's PR or issue if it's not a small, obvious fix;
|
||||
followed by an -- empty line -- ]
|
||||
[Bug: URL to the source of the report or more related discussion; use Fixes
|
||||
for GitHub issues instead when that is appropriate]
|
||||
[Approved-by: John Doe - credit someone who approved the PR; if you're
|
||||
committing this for someone else using --author=... you don't need this
|
||||
as you're implicitly approving it by committing]
|
||||
[Authored-by: John Doe - credit the original author of the code; only use
|
||||
this if you can't use "git commit --author=..."]
|
||||
{Signed-off-by: John Doe - we don't use this, but don't bother removing it]
|
||||
[whatever-else-by: credit all helpers, finders, doers; try to use one of
|
||||
the following keywords if at all possible, for consistency:
|
||||
Acked-by:, Assisted-by:, Co-authored-by:, Found-by:, Reported-by:,
|
||||
Reviewed-by:, Suggested-by:, Tested-by:]
|
||||
[Ref: #1234 - if this is related to a GitHub issue or PR, possibly one that
|
||||
has already been closed]
|
||||
[Ref: URL to more information about the commit; use Bug: instead for
|
||||
a reference to a bug on another bug tracker]
|
||||
[Fixes #1234 - if this closes a GitHub issue; GitHub will actually
|
||||
close the issue once this commit is merged]
|
||||
[Closes #1234 - if this closes a GitHub PR; GitHub will actually
|
||||
close the PR once this commit is merged]
|
||||
---- stop ----
|
||||
|
||||
The first line is a succinct description of the change:
|
||||
|
||||
- use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
- do not capitalize the first letter
|
||||
- no period (.) at the end
|
||||
|
||||
The `[area]` in the first line can be `http2`, `cookies`, `openssl` or
|
||||
similar. There's no fixed list to select from but using the same "area" as
|
||||
other related changes could make sense.
|
||||
|
||||
Do not forget to use commit --author=... if you commit someone else's work, and
|
||||
make sure that you have your own user and email setup correctly in git before
|
||||
you commit.
|
||||
|
||||
Add whichever header lines as appropriate, with one line per person if more
|
||||
than one person was involved. There's no need to credit yourself unless you are
|
||||
using --author=... which hides your identity. Don't include people's e-mail
|
||||
addresses in headers to avoid spam, unless they're already public from a
|
||||
previous commit; saying `{userid} on github` is OK.
|
||||
|
||||
### Write Access to git Repository
|
||||
|
||||
If you are a frequent contributor, you may be given push access to the git
|
||||
repository and then you will be able to push your changes straight into the git
|
||||
repo instead of sending changes as pull requests or by mail as patches.
|
||||
|
||||
Just ask if this is what you would want. You will be required to have posted
|
||||
several high quality patches first, before you can be granted push access.
|
||||
|
||||
### How To Make a Patch with git
|
||||
|
||||
You need to first checkout the repository:
|
||||
|
||||
git clone https://github.com/curl/curl.git
|
||||
|
||||
You then proceed and edit all the files you like and you commit them to your
|
||||
local repository:
|
||||
|
||||
git commit [file]
|
||||
|
||||
As usual, group your commits so that you commit all changes at once that
|
||||
constitute a logical change.
|
||||
|
||||
Once you have done all your commits and you are happy with what you see, you
|
||||
can make patches out of your changes that are suitable for mailing:
|
||||
|
||||
git format-patch remotes/origin/master
|
||||
|
||||
This creates files in your local directory named `NNNN-[name].patch` for each
|
||||
commit.
|
||||
|
||||
Now send those patches off to the curl-library list. You can of course opt to
|
||||
do that with the 'git send-email' command.
|
||||
|
||||
### How To Make a Patch without git
|
||||
|
||||
Keep a copy of the unmodified curl sources. Make your changes in a separate
|
||||
source tree. When you think you have something that you want to offer the
|
||||
curl community, use GNU diff to generate patches.
|
||||
|
||||
If you have modified a single file, try something like:
|
||||
|
||||
diff -u unmodified-file.c my-changed-one.c > my-fixes.diff
|
||||
|
||||
If you have modified several files, possibly in different directories, you
|
||||
can use diff recursively:
|
||||
|
||||
diff -ur curl-original-dir curl-modified-sources-dir > my-fixes.diff
|
||||
|
||||
The GNU diff and GNU patch tools exist for virtually all platforms, including
|
||||
all kinds of Unixes and Windows.
|
||||
|
||||
### Useful resources
|
||||
- [Webinar on getting code into cURL](https://www.youtube.com/watch?v=QmZ3W1d6LQI)
|
||||
|
||||
## Update copyright and license information
|
||||
|
||||
There is a CI job called **REUSE compliance / check** that will run on every
|
||||
pull request and commit to verify that the *REUSE state* of all files are
|
||||
still fine.
|
||||
|
||||
This means that all files need to have their license and copyright information
|
||||
clearly stated. Ideally by having the standard curl source code header, with
|
||||
an accurate copyright year range and the SPDX-License-Identifier included. If
|
||||
the header does not work, you can use a smaller header or add the information
|
||||
for a specific file to the `.reuse/dep5` file.
|
||||
|
||||
We update copyright year ranges to end on the year of the most recent change
|
||||
of the individual file.
|
||||
|
||||
You can manually verify the copyright and compliance status by running the
|
||||
`./scripts/copyright.pl` script in the root of the git repository.
|
||||
@ -0,0 +1,140 @@
|
||||
# Code defines to disable features and protocols
|
||||
|
||||
## `CURL_DISABLE_ALTSVC`
|
||||
|
||||
Disable support for Alt-Svc: HTTP headers.
|
||||
|
||||
## `CURL_DISABLE_COOKIES`
|
||||
|
||||
Disable support for HTTP cookies.
|
||||
|
||||
## `CURL_DISABLE_CRYPTO_AUTH`
|
||||
|
||||
Disable support for authentication methods using crypto.
|
||||
|
||||
## `CURL_DISABLE_DICT`
|
||||
|
||||
Disable the DICT protocol
|
||||
|
||||
## `CURL_DISABLE_DOH`
|
||||
|
||||
Disable DNS-over-HTTPS
|
||||
|
||||
## `CURL_DISABLE_FILE`
|
||||
|
||||
Disable the FILE protocol
|
||||
|
||||
## `CURL_DISABLE_FTP`
|
||||
|
||||
Disable the FTP (and FTPS) protocol
|
||||
|
||||
## `CURL_DISABLE_GETOPTIONS`
|
||||
|
||||
Disable the `curl_easy_options` API calls that lets users get information
|
||||
about existing options to `curl_easy_setopt`.
|
||||
|
||||
## `CURL_DISABLE_GOPHER`
|
||||
|
||||
Disable the GOPHER protocol.
|
||||
|
||||
## `CURL_DISABLE_HEADERS_API`
|
||||
|
||||
Disable the HTTP header API.
|
||||
|
||||
## `CURL_DISABLE_HSTS`
|
||||
|
||||
Disable the HTTP Strict Transport Security support.
|
||||
|
||||
## `CURL_DISABLE_HTTP`
|
||||
|
||||
Disable the HTTP(S) protocols. Note that this then also disable HTTP proxy
|
||||
support.
|
||||
|
||||
## `CURL_DISABLE_HTTP_AUTH`
|
||||
|
||||
Disable support for all HTTP authentication methods.
|
||||
|
||||
## `CURL_DISABLE_IMAP`
|
||||
|
||||
Disable the IMAP(S) protocols.
|
||||
|
||||
## `CURL_DISABLE_LDAP`
|
||||
|
||||
Disable the LDAP(S) protocols.
|
||||
|
||||
## `CURL_DISABLE_LDAPS`
|
||||
|
||||
Disable the LDAPS protocol.
|
||||
|
||||
## `CURL_DISABLE_LIBCURL_OPTION`
|
||||
|
||||
Disable the --libcurl option from the curl tool.
|
||||
|
||||
## `CURL_DISABLE_MIME`
|
||||
|
||||
Disable MIME support.
|
||||
|
||||
## `CURL_DISABLE_MQTT`
|
||||
|
||||
Disable MQTT support.
|
||||
|
||||
## `CURL_DISABLE_NETRC`
|
||||
|
||||
Disable the netrc parser.
|
||||
|
||||
## `CURL_DISABLE_NTLM`
|
||||
|
||||
Disable support for NTLM.
|
||||
|
||||
## `CURL_DISABLE_OPENSSL_AUTO_LOAD_CONFIG`
|
||||
|
||||
Disable the auto load config support in the OpenSSL backend.
|
||||
|
||||
## `CURL_DISABLE_PARSEDATE`
|
||||
|
||||
Disable date parsing
|
||||
|
||||
## `CURL_DISABLE_POP3`
|
||||
|
||||
Disable the POP3 protocol
|
||||
|
||||
## `CURL_DISABLE_PROGRESS_METER`
|
||||
|
||||
Disable the built-in progress meter
|
||||
|
||||
## `CURL_DISABLE_PROXY`
|
||||
|
||||
Disable support for proxies
|
||||
|
||||
## `CURL_DISABLE_RTSP`
|
||||
|
||||
Disable the RTSP protocol.
|
||||
|
||||
## `CURL_DISABLE_SHUFFLE_DNS`
|
||||
|
||||
Disable the shuffle DNS feature
|
||||
|
||||
## `CURL_DISABLE_SMB`
|
||||
|
||||
Disable the SMB(S) protocols
|
||||
|
||||
## `CURL_DISABLE_SMTP`
|
||||
|
||||
Disable the SMTP(S) protocols
|
||||
|
||||
## `CURL_DISABLE_SOCKETPAIR`
|
||||
|
||||
Disable the use of `socketpair()` internally to allow waking up and canceling
|
||||
`curl_multi_poll()`.
|
||||
|
||||
## `CURL_DISABLE_TELNET`
|
||||
|
||||
Disable the TELNET protocol
|
||||
|
||||
## `CURL_DISABLE_TFTP`
|
||||
|
||||
Disable the TFTP protocol
|
||||
|
||||
## `CURL_DISABLE_VERBOSE_STRINGS`
|
||||
|
||||
Disable verbose strings and error messages.
|
||||
@ -0,0 +1,71 @@
|
||||
# Items to be removed from future curl releases
|
||||
|
||||
If any of these deprecated features is a cause for concern for you, please
|
||||
email the
|
||||
[curl-library mailing list](https://lists.haxx.se/listinfo/curl-library)
|
||||
as soon as possible and explain to us why this is a problem for you and
|
||||
how your use case cannot be satisfied properly using a workaround.
|
||||
|
||||
## NSS
|
||||
|
||||
We remove support for building curl with the NSS TLS library in August 2023.
|
||||
|
||||
- There are few users left who use curl+NSS
|
||||
- NSS has few users outside of curl as well (primarily Firefox)
|
||||
- NSS is harder than ever to find documentation for
|
||||
- NSS was always "best" used with Red Hat Linux when they provided additional
|
||||
features on top of the regular NSS that is not shipped by the vanilla library
|
||||
|
||||
Starting in 7.82.0, building curl to use NSS configure requires the additional
|
||||
flag `--with-nss-deprecated` in an attempt to highlight these plans.
|
||||
|
||||
## gskit
|
||||
|
||||
We remove support for building curl with the gskit TLS library in August 2023.
|
||||
|
||||
- This is a niche TLS library, only running on some IBM systems
|
||||
- no regular curl contributors use this backend
|
||||
- no CI builds use or verify this backend
|
||||
- gskit, or the curl adaption for it, lacks many modern TLS features making it
|
||||
an inferior solution
|
||||
- build breakages in this code take weeks or more to get detected
|
||||
- fixing gskit code is mostly done "flying blind"
|
||||
|
||||
## mingw v1
|
||||
|
||||
We remove support for building curl with the original legacy mingw version 1
|
||||
in September 2023.
|
||||
|
||||
During the deprecation period you can enable the support with the configure
|
||||
option `--with-mingw1-deprecated`.
|
||||
|
||||
mingw version 1 is old and deprecated software. There are much better and
|
||||
still support build environments to use to build curl and other software. For
|
||||
example [MinGW-w64](https://www.mingw-w64.org/).
|
||||
|
||||
## space-separated `NOPROXY` patterns
|
||||
|
||||
When specifying patterns/domain names for curl that should *not* go through a
|
||||
proxy, the curl tool features the `--noproxy` command line option and the
|
||||
library supports the `NO_PROXY` environment variable and the `CURLOPT_NOPROXY`
|
||||
libcurl option.
|
||||
|
||||
They all set the same list of patterns. This list is documented to be a set of
|
||||
**comma-separated** names, but can also be provided separated with just
|
||||
space. The ability to just use spaces for this has never been documented but
|
||||
some users may still have come to rely on this.
|
||||
|
||||
Several other tools and utilities also parse the `NO_PROXY` environment
|
||||
variable but do not consider a space to be a valid separator. Using spaces for
|
||||
separator is probably less portable and might cause more friction than commas
|
||||
do. Users should use commas for this for greater portability.
|
||||
|
||||
curl will remove the support for space-separated names in July 2024.
|
||||
|
||||
## past removals
|
||||
|
||||
- Pipelining
|
||||
- axTLS
|
||||
- PolarSSL
|
||||
- NPN
|
||||
- Support for systems without 64 bit data types
|
||||
@ -0,0 +1,128 @@
|
||||
# dynbuf
|
||||
|
||||
This is the internal module for creating and handling "dynamic buffers". This
|
||||
means buffers that can be appended to, dynamically and grow to adapt.
|
||||
|
||||
There will always be a terminating zero put at the end of the dynamic buffer.
|
||||
|
||||
The `struct dynbuf` is used to hold data for each instance of a dynamic
|
||||
buffer. The members of that struct **MUST NOT** be accessed or modified
|
||||
without using the dedicated dynbuf API.
|
||||
|
||||
## `Curl_dyn_init`
|
||||
|
||||
```c
|
||||
void Curl_dyn_init(struct dynbuf *s, size_t toobig);
|
||||
```
|
||||
|
||||
This initializes a struct to use for dynbuf and it cannot fail. The `toobig`
|
||||
value **must** be set to the maximum size we allow this buffer instance to
|
||||
grow to. The functions below will return `CURLE_OUT_OF_MEMORY` when hitting
|
||||
this limit.
|
||||
|
||||
## `Curl_dyn_free`
|
||||
|
||||
```c
|
||||
void Curl_dyn_free(struct dynbuf *s);
|
||||
```
|
||||
|
||||
Free the associated memory and clean up. After a free, the `dynbuf` struct can
|
||||
be re-used to start appending new data to.
|
||||
|
||||
## `Curl_dyn_addn`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_addn(struct dynbuf *s, const void *mem, size_t len);
|
||||
```
|
||||
|
||||
Append arbitrary data of a given length to the end of the buffer.
|
||||
|
||||
If this function fails it calls `Curl_dyn_free` on `dynbuf`.
|
||||
|
||||
## `Curl_dyn_add`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_add(struct dynbuf *s, const char *str);
|
||||
```
|
||||
|
||||
Append a C string to the end of the buffer.
|
||||
|
||||
If this function fails it calls `Curl_dyn_free` on `dynbuf`.
|
||||
|
||||
## `Curl_dyn_addf`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_addf(struct dynbuf *s, const char *fmt, ...);
|
||||
```
|
||||
|
||||
Append a `printf()`-style string to the end of the buffer.
|
||||
|
||||
If this function fails it calls `Curl_dyn_free` on `dynbuf`.
|
||||
|
||||
## `Curl_dyn_vaddf`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_vaddf(struct dynbuf *s, const char *fmt, va_list ap);
|
||||
```
|
||||
|
||||
Append a `vprintf()`-style string to the end of the buffer.
|
||||
|
||||
If this function fails it calls `Curl_dyn_free` on `dynbuf`.
|
||||
|
||||
## `Curl_dyn_reset`
|
||||
|
||||
```c
|
||||
void Curl_dyn_reset(struct dynbuf *s);
|
||||
```
|
||||
|
||||
Reset the buffer length, but leave the allocation.
|
||||
|
||||
## `Curl_dyn_tail`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_tail(struct dynbuf *s, size_t length);
|
||||
```
|
||||
|
||||
Keep `length` bytes of the buffer tail (the last `length` bytes of the
|
||||
buffer). The rest of the buffer is dropped. The specified `length` must not be
|
||||
larger than the buffer length. To instead keep the leading part, see
|
||||
`Curl_dyn_setlen()`.
|
||||
|
||||
## `Curl_dyn_ptr`
|
||||
|
||||
```c
|
||||
char *Curl_dyn_ptr(const struct dynbuf *s);
|
||||
```
|
||||
|
||||
Returns a `char *` to the buffer if it has a length, otherwise may return
|
||||
NULL. Since the buffer may be reallocated, this pointer should not be trusted
|
||||
or used anymore after the next buffer manipulation call.
|
||||
|
||||
## `Curl_dyn_uptr`
|
||||
|
||||
```c
|
||||
unsigned char *Curl_dyn_uptr(const struct dynbuf *s);
|
||||
```
|
||||
|
||||
Returns an `unsigned char *` to the buffer if it has a length, otherwise may
|
||||
return NULL. Since the buffer may be reallocated, this pointer should not be
|
||||
trusted or used anymore after the next buffer manipulation call.
|
||||
|
||||
## `Curl_dyn_len`
|
||||
|
||||
```c
|
||||
size_t Curl_dyn_len(const struct dynbuf *s);
|
||||
```
|
||||
|
||||
Returns the length of the buffer in bytes. Does not include the terminating
|
||||
zero byte.
|
||||
|
||||
## `Curl_dyn_setlen`
|
||||
|
||||
```c
|
||||
CURLcode Curl_dyn_setlen(struct dynbuf *s, size_t len);
|
||||
```
|
||||
|
||||
Sets the new shorter length of the buffer in number of bytes. Keeps the
|
||||
leftmost set number of bytes, discards the rest. To instead keep the tail part
|
||||
of the buffer, see `Curl_dyn_tail()`.
|
||||
@ -0,0 +1,66 @@
|
||||
# How to determine if an early patch release is warranted
|
||||
|
||||
In the curl project we do releases every 8 weeks. Unless we break the cycle
|
||||
and do an early patch release.
|
||||
|
||||
We do frequent releases partly to always have the next release "not too far
|
||||
away".
|
||||
|
||||
## Bugfix
|
||||
|
||||
During the release cycle, and especially in the beginning of a new cycle,
|
||||
there are times when a bug is reported and after it has been subsequently
|
||||
fixed correctly, the discussion might be brought up: is this bug and
|
||||
associated fix important enough for an early patch release.
|
||||
|
||||
The question can only be properly asked once a fix has been created and landed
|
||||
in the git master branch.
|
||||
|
||||
## Early release
|
||||
|
||||
An early patch release means that we ship a new, complete and full release
|
||||
called `major.minor.patch` where the `patch` part is increased by one since
|
||||
the previous release. A curl release is a curl release. There is no small or
|
||||
big and we never release just a patch. There is only "release".
|
||||
|
||||
## Questions to ask
|
||||
|
||||
- Is there a security advisory rated high or critical?
|
||||
- Is there a data corruption bug?
|
||||
- Did the bug cause an API/ABI breakage?
|
||||
|
||||
If the answer is yes to one or more of the above, an early release might
|
||||
indeed be warranted.
|
||||
|
||||
More questions to ask ourselves when doing the assessment if the answers to
|
||||
the three ones above are all 'no'.
|
||||
|
||||
- Does the bug cause curl to prematurely terminate?
|
||||
- How common is the affected buggy option/feature/protocol/platform to get
|
||||
used?
|
||||
- How large is the estimated impacted user base?
|
||||
- Does the bug block something crucial for applications or other adoption of
|
||||
curl "out there" ?
|
||||
- Does the bug cause problems for curl developers or others on "the curl
|
||||
team" ?
|
||||
- Is the bug limited to the curl tool only? That might have a smaller impact
|
||||
than a bug also present in libcurl.
|
||||
- Is there a (decent) workaround?
|
||||
- Is it a regression? Is the bug introduced in this release?
|
||||
- Can the bug be fixed "easily" by applying a patch?
|
||||
- Does the bug break the build? Most users don't build curl themselves.
|
||||
- How long is it left until the already scheduled next release?
|
||||
- Can affected users safely rather revert to a former release until the next
|
||||
scheduled release?
|
||||
- Is it a performance regression with no functionality side-effects? If so it
|
||||
has to be substantial.
|
||||
|
||||
## If an early release is deemed necessary
|
||||
|
||||
Unless done for security or similarly important reasons, an early release
|
||||
should never be done within two weeks of the release of the previous version.
|
||||
|
||||
This, to enable us to collect and bundle more fixes into the same release to
|
||||
make the release more worthwhile for everyone and to allow more time for fixes
|
||||
to settle and things to get tested. Getting a release in shape and done in
|
||||
style is work that should not be rushed.
|
||||
@ -0,0 +1,24 @@
|
||||
# Experimental
|
||||
|
||||
Some features and functionality in curl and libcurl are considered
|
||||
**EXPERIMENTAL**.
|
||||
|
||||
Experimental support in curl means:
|
||||
|
||||
1. Experimental features are provided to allow users to try them out and
|
||||
provide feedback on functionality and API etc before they ship and get
|
||||
"carved in stone".
|
||||
2. You must enable the feature when invoking configure as otherwise curl will
|
||||
not be built with the feature present.
|
||||
3. We strongly advise against using this feature in production.
|
||||
4. **We reserve the right to change behavior** of the feature without sticking
|
||||
to our API/ABI rules as we do for regular features, as long as it is marked
|
||||
experimental.
|
||||
5. Experimental features are clearly marked so in documentation. Beware.
|
||||
|
||||
## Experimental features right now
|
||||
|
||||
- The Hyper HTTP backend
|
||||
- HTTP/3 support and options
|
||||
- The rustls backend
|
||||
- WebSocket
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
@ -0,0 +1,219 @@
|
||||
# Features -- what curl can do
|
||||
|
||||
## curl tool
|
||||
|
||||
- config file support
|
||||
- multiple URLs in a single command line
|
||||
- range "globbing" support: [0-13], {one,two,three}
|
||||
- multiple file upload on a single command line
|
||||
- custom maximum transfer rate
|
||||
- redirect stderr
|
||||
- parallel transfers
|
||||
|
||||
## libcurl
|
||||
|
||||
- full URL syntax with no length limit
|
||||
- custom maximum download time
|
||||
- custom least download speed acceptable
|
||||
- custom output result after completion
|
||||
- guesses protocol from host name unless specified
|
||||
- uses .netrc
|
||||
- progress bar with time statistics while downloading
|
||||
- "standard" proxy environment variables support
|
||||
- compiles on win32 (reported builds on 70+ operating systems)
|
||||
- selectable network interface for outgoing traffic
|
||||
- IPv6 support on Unix and Windows
|
||||
- happy eyeballs dual-stack connects
|
||||
- persistent connections
|
||||
- SOCKS 4 + 5 support, with or without local name resolving
|
||||
- supports user name and password in proxy environment variables
|
||||
- operations through HTTP proxy "tunnel" (using CONNECT)
|
||||
- replaceable memory functions (malloc, free, realloc, etc)
|
||||
- asynchronous name resolving (6)
|
||||
- both a push and a pull style interface
|
||||
- international domain names (10)
|
||||
|
||||
## HTTP
|
||||
|
||||
- HTTP/0.9 responses are optionally accepted
|
||||
- HTTP/1.0
|
||||
- HTTP/1.1
|
||||
- HTTP/2, including multiplexing and server push (5)
|
||||
- GET
|
||||
- PUT
|
||||
- HEAD
|
||||
- POST
|
||||
- multipart formpost (RFC1867-style)
|
||||
- authentication: Basic, Digest, NTLM (9) and Negotiate (SPNEGO) (3)
|
||||
to server and proxy
|
||||
- resume (both GET and PUT)
|
||||
- follow redirects
|
||||
- maximum amount of redirects to follow
|
||||
- custom HTTP request
|
||||
- cookie get/send fully parsed
|
||||
- reads/writes the Netscape cookie file format
|
||||
- custom headers (replace/remove internally generated headers)
|
||||
- custom user-agent string
|
||||
- custom referrer string
|
||||
- range
|
||||
- proxy authentication
|
||||
- time conditions
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- retrieve file modification date
|
||||
- Content-Encoding support for deflate and gzip
|
||||
- "Transfer-Encoding: chunked" support in uploads
|
||||
- automatic data compression (11)
|
||||
|
||||
## HTTPS (1)
|
||||
|
||||
- (all the HTTP features)
|
||||
- HTTP/3 experimental support
|
||||
- using client certificates
|
||||
- verify server certificate
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- select desired encryption
|
||||
- select usage of a specific SSL version
|
||||
|
||||
## FTP
|
||||
|
||||
- download
|
||||
- authentication
|
||||
- Kerberos 5 (12)
|
||||
- active/passive using PORT, EPRT, PASV or EPSV
|
||||
- single file size information (compare to HTTP HEAD)
|
||||
- 'type=' URL support
|
||||
- dir listing
|
||||
- dir listing names-only
|
||||
- upload
|
||||
- upload append
|
||||
- upload via http-proxy as HTTP PUT
|
||||
- download resume
|
||||
- upload resume
|
||||
- custom ftp commands (before and/or after the transfer)
|
||||
- simple "range" support
|
||||
- via HTTP proxy, HTTPS proxy or SOCKS proxy
|
||||
- all operations can be tunneled through proxy
|
||||
- customizable to retrieve file modification date
|
||||
- no dir depth limit
|
||||
|
||||
## FTPS (1)
|
||||
|
||||
- implicit `ftps://` support that use SSL on both connections
|
||||
- explicit "AUTH TLS" and "AUTH SSL" usage to "upgrade" plain `ftp://`
|
||||
connection to use SSL for both or one of the connections
|
||||
|
||||
## SCP (8)
|
||||
|
||||
- both password and public key auth
|
||||
|
||||
## SFTP (7)
|
||||
|
||||
- both password and public key auth
|
||||
- with custom commands sent before/after the transfer
|
||||
|
||||
## TFTP
|
||||
|
||||
- download
|
||||
- upload
|
||||
|
||||
## TELNET
|
||||
|
||||
- connection negotiation
|
||||
- custom telnet options
|
||||
- stdin/stdout I/O
|
||||
|
||||
## LDAP (2)
|
||||
|
||||
- full LDAP URL support
|
||||
|
||||
## DICT
|
||||
|
||||
- extended DICT URL support
|
||||
|
||||
## FILE
|
||||
|
||||
- URL support
|
||||
- upload
|
||||
- resume
|
||||
|
||||
## SMB
|
||||
|
||||
- SMBv1 over TCP and SSL
|
||||
- download
|
||||
- upload
|
||||
- authentication with NTLMv1
|
||||
|
||||
## SMTP
|
||||
|
||||
- authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM (9), Kerberos 5
|
||||
(4) and External.
|
||||
- send emails
|
||||
- mail from support
|
||||
- mail size support
|
||||
- mail auth support for trusted server-to-server relaying
|
||||
- multiple recipients
|
||||
- via http-proxy
|
||||
|
||||
## SMTPS (1)
|
||||
|
||||
- implicit `smtps://` support
|
||||
- explicit "STARTTLS" usage to "upgrade" plain `smtp://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## POP3
|
||||
|
||||
- authentication: Clear Text, APOP and SASL
|
||||
- SASL based authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM (9),
|
||||
Kerberos 5 (4) and External.
|
||||
- list emails
|
||||
- retrieve emails
|
||||
- enhanced command support for: CAPA, DELE, TOP, STAT, UIDL and NOOP via
|
||||
custom requests
|
||||
- via http-proxy
|
||||
|
||||
## POP3S (1)
|
||||
|
||||
- implicit `pop3s://` support
|
||||
- explicit `STLS` usage to "upgrade" plain `pop3://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## IMAP
|
||||
|
||||
- authentication: Clear Text and SASL
|
||||
- SASL based authentication: Plain, Login, CRAM-MD5, Digest-MD5, NTLM (9),
|
||||
Kerberos 5 (4) and External.
|
||||
- list the folders of a mailbox
|
||||
- select a mailbox with support for verifying the `UIDVALIDITY`
|
||||
- fetch emails with support for specifying the UID and SECTION
|
||||
- upload emails via the append command
|
||||
- enhanced command support for: EXAMINE, CREATE, DELETE, RENAME, STATUS,
|
||||
STORE, COPY and UID via custom requests
|
||||
- via http-proxy
|
||||
|
||||
## IMAPS (1)
|
||||
|
||||
- implicit `imaps://` support
|
||||
- explicit "STARTTLS" usage to "upgrade" plain `imap://` connections to use SSL
|
||||
- via http-proxy
|
||||
|
||||
## MQTT
|
||||
|
||||
- Subscribe to and publish topics using URL scheme `mqtt://broker/topic`
|
||||
|
||||
## Footnotes
|
||||
|
||||
1. requires a TLS library
|
||||
2. requires OpenLDAP or WinLDAP
|
||||
3. requires a GSS-API implementation (such as Heimdal or MIT Kerberos) or
|
||||
SSPI (native Windows)
|
||||
4. requires a GSS-API implementation, however, only Windows SSPI is
|
||||
currently supported
|
||||
5. requires nghttp2
|
||||
6. requires c-ares
|
||||
7. requires libssh2, libssh or wolfSSH
|
||||
8. requires libssh2 or libssh
|
||||
9. requires OpenSSL, GnuTLS, mbedTLS, NSS, Secure Transport or SSPI
|
||||
(native Windows)
|
||||
10. requires libidn2 or Windows
|
||||
11. requires libz, brotli and/or zstd
|
||||
12. requires a GSS-API implementation (such as Heimdal or MIT Kerberos)
|
||||
@ -0,0 +1,182 @@
|
||||
# Decision making in the curl project
|
||||
|
||||
A rough guide to how we make decisions and who does what.
|
||||
|
||||
## BDFL
|
||||
|
||||
This project was started by and has to some extent been pushed forward over
|
||||
the years with Daniel Stenberg as the driving force. It matches a standard
|
||||
BDFL (Benevolent Dictator For Life) style project.
|
||||
|
||||
This setup has been used due to convenience and the fact that it has worked
|
||||
fine this far. It is not because someone thinks of it as a superior project
|
||||
leadership model. It will also only continue working as long as Daniel manages
|
||||
to listen in to what the project and the general user population wants and
|
||||
expects from us.
|
||||
|
||||
## Legal entity
|
||||
|
||||
There is no legal entity. The curl project is just a bunch of people scattered
|
||||
around the globe with the common goal to produce source code that creates
|
||||
great products. We are not part of any umbrella organization and we are not
|
||||
located in any specific country. We are totally independent.
|
||||
|
||||
The copyrights in the project are owned by the individuals and organizations
|
||||
that wrote those parts of the code.
|
||||
|
||||
## Decisions
|
||||
|
||||
The curl project is not a democracy, but everyone is entitled to state their
|
||||
opinion and may argue for their sake within the community.
|
||||
|
||||
All and any changes that have been done or will be done are eligible to bring
|
||||
up for discussion, to object to or to praise. Ideally, we find consensus for
|
||||
the appropriate way forward in any given situation or challenge.
|
||||
|
||||
If there is no obvious consensus, a maintainer who's knowledgeable in the
|
||||
specific area will take an "executive" decision that they think is the right
|
||||
for the project.
|
||||
|
||||
## Donations
|
||||
|
||||
Donating plain money to curl is best done to curl's [Open Collective
|
||||
fund](https://opencollective.com/curl). Open Collective is a US based
|
||||
non-profit organization that holds on to funds for us. This fund is then used
|
||||
for paying the curl security bug bounties, to reimburse project related
|
||||
expenses etc.
|
||||
|
||||
Donations to the project can also come in the form of server hosting, providing
|
||||
services and paying for people to work on curl related code etc. Usually, such
|
||||
donations are services paid for directly by the sponsors.
|
||||
|
||||
We grade sponsors in a few different levels and if they meet the criteria,
|
||||
they can be mentioned on the Sponsors page on the curl website.
|
||||
|
||||
## Commercial Support
|
||||
|
||||
The curl project does not do or offer commercial support. It only hosts
|
||||
mailing lists, runs bug trackers etc to facilitate communication and work.
|
||||
|
||||
However, Daniel works for wolfSSL and we offer commercial curl support there.
|
||||
|
||||
# Key roles
|
||||
|
||||
## User
|
||||
|
||||
Someone who uses or has used curl or libcurl.
|
||||
|
||||
## Contributor
|
||||
|
||||
Someone who has helped the curl project, who has contributed to bring it
|
||||
forward. Contributing could be to provide advice, debug a problem, file a bug
|
||||
report, run test infrastructure or writing code etc.
|
||||
|
||||
## Commit author
|
||||
|
||||
Sometimes also called 'committer'. Someone who has authored a commit in the
|
||||
curl source code repository. Committers are recorded as `Author` in git.
|
||||
|
||||
## Maintainers
|
||||
|
||||
A maintainer in the curl project is an individual who has been given
|
||||
permissions to push commits to one of the git repositories.
|
||||
|
||||
Maintainers are free to push commits to the repositories at their own will.
|
||||
Maintainers are however expected to listen to feedback from users and any
|
||||
change that is non-trivial in size or nature *should* be brought to the
|
||||
project as a Pull-Request (PR) to allow others to comment/object before merge.
|
||||
|
||||
## Former maintainers
|
||||
|
||||
A maintainer who stops being active in the project will at some point get
|
||||
their push permissions removed. We do this for security reasons but also to
|
||||
make sure that we always have the list of maintainers as "the team that push
|
||||
stuff to curl".
|
||||
|
||||
Getting push permissions removed is not a punishment. Everyone who ever worked
|
||||
on maintaining curl is considered a hero, for all time hereafter.
|
||||
|
||||
## Security team members
|
||||
|
||||
We have a security team. That is the team of people who are subscribed to the
|
||||
curl-security mailing list; the receivers of security reports from users and
|
||||
developers. This list of people will vary over time but should be skilled
|
||||
developers familiar with the curl project.
|
||||
|
||||
The security team works best when it consists of a small set of active
|
||||
persons. We invite new members when the team seems to need it, and we also
|
||||
expect to retire security team members as they "drift off" from the project or
|
||||
just find themselves unable to perform their duties there.
|
||||
|
||||
## Server admins
|
||||
|
||||
We run a web server, a mailing list and more on the curl project's primary
|
||||
server. That physical machine is owned and run by Haxx. Daniel is the primary
|
||||
admin of all things curl related server stuff, but Björn Stenberg and Linus
|
||||
Feltzing serve as backup admins for when Daniel is gone or unable.
|
||||
|
||||
The primary server is paid for by Haxx. The machine is physically located in a
|
||||
server bunker in Stockholm Sweden, operated by the company Glesys.
|
||||
|
||||
The website contents are served to the web via Fastly and Daniel is the
|
||||
primary curl contact with Fastly.
|
||||
|
||||
## BDFL
|
||||
|
||||
That is Daniel.
|
||||
|
||||
# Maintainers
|
||||
|
||||
A curl maintainer is a project volunteer who has the authority and rights to
|
||||
merge changes into a git repository in the curl project.
|
||||
|
||||
Anyone can aspire to become a curl maintainer.
|
||||
|
||||
### Duties
|
||||
|
||||
There are no mandatory duties. We hope and wish that maintainers consider
|
||||
reviewing patches and help merging them, especially when the changes are
|
||||
within the area of personal expertise and experience.
|
||||
|
||||
### Requirements
|
||||
|
||||
- only merge code that meets our quality and style guide requirements.
|
||||
- *never* merge code without doing a PR first, unless the change is "trivial"
|
||||
- if in doubt, ask for input/feedback from others
|
||||
|
||||
### Recommendations
|
||||
|
||||
- we require two-factor authentication enabled on your GitHub account to
|
||||
reduce risk of malicious source code tampering
|
||||
- consider enabling signed git commits for additional verification of changes
|
||||
|
||||
### Merge advice
|
||||
|
||||
When you are merging patches/pull requests...
|
||||
|
||||
- make sure the commit messages follow our template
|
||||
- squash patch sets into a few logical commits even if the PR did not, if
|
||||
necessary
|
||||
- avoid the "merge" button on GitHub, do it "manually" instead to get full
|
||||
control and full audit trail (GitHub leaves out you as "Committer:")
|
||||
- remember to credit the reporter and the helpers.
|
||||
|
||||
## Who are maintainers?
|
||||
|
||||
The [list of maintainers](https://github.com/orgs/curl/people). Be aware that
|
||||
the level of presence and activity in the project vary greatly between
|
||||
different individuals and over time.
|
||||
|
||||
### Become a maintainer?
|
||||
|
||||
If you think you can help making the project better by shouldering some
|
||||
maintaining responsibilities, then please get in touch.
|
||||
|
||||
You will be expected to be familiar with the curl project and its ways of
|
||||
working. You need to have gotten a few quality patches merged as a proof of
|
||||
this.
|
||||
|
||||
### Stop being a maintainer
|
||||
|
||||
If you (appear to) not be active in the project anymore, you may be removed as
|
||||
a maintainer. Thank you for your service!
|
||||
@ -0,0 +1,89 @@
|
||||
# How to get started helping out in the curl project
|
||||
|
||||
We are always in need of more help. If you are new to the project and are
|
||||
looking for ways to contribute and help out, this document aims to give a few
|
||||
good starting points.
|
||||
|
||||
You may subscribe to the [curl-library mailing
|
||||
list](https://lists.haxx.se/listinfo/curl-library) to keep track of the
|
||||
current discussion topics; or if you are registered on GitHub, you can use the
|
||||
[Discussions section](https://github.com/curl/curl/discussions) on the main
|
||||
curl repository.
|
||||
|
||||
## Scratch your own itch
|
||||
|
||||
One of the best ways is to start working on any problems or issues you have
|
||||
found yourself or perhaps got annoyed at in the past. It can be a spelling
|
||||
error in an error text or a weirdly phrased section in a man page. Hunt it
|
||||
down and report the bug. Or make your first pull request with a fix for that.
|
||||
|
||||
## Smaller tasks
|
||||
|
||||
Some projects mark small issues as "beginner friendly", "bite-sized" or
|
||||
similar. We do not do that in curl since such issues never linger around long
|
||||
enough. Simple issues get handled fast.
|
||||
|
||||
If you are looking for a smaller or simpler task in the project to help out
|
||||
with as an entry-point into the project, perhaps because you are a newcomer or
|
||||
even maybe not a terribly experienced developer, here's our advice:
|
||||
|
||||
- Read through this document to get a grasp on a general approach to use
|
||||
- Consider adding a test case for something not currently tested (correctly)
|
||||
- Consider updating or adding documentation
|
||||
- One way to get started gently in the project, is to participate in an
|
||||
existing issue/PR and help out by reproducing the issue, review the code in
|
||||
the PR etc.
|
||||
|
||||
## Help wanted
|
||||
|
||||
In the issue tracker we occasionally mark bugs with [help
|
||||
wanted](https://github.com/curl/curl/labels/help%20wanted), as a sign that the
|
||||
bug is acknowledged to exist and that there's nobody known to work on this
|
||||
issue for the moment. Those are bugs that are fine to "grab" and provide a
|
||||
pull request for. The complexity level of these will of course vary, so pick
|
||||
one that piques your interest.
|
||||
|
||||
## Work on known bugs
|
||||
|
||||
Some bugs are known and have not yet received attention and work enough to get
|
||||
fixed. We collect such known existing flaws in the
|
||||
[KNOWN_BUGS](https://curl.se/docs/knownbugs.html) page. Many of them link
|
||||
to the original bug report with some additional details, but some may also
|
||||
have aged a bit and may require some verification that the bug still exists in
|
||||
the same way and that what was said about it in the past is still valid.
|
||||
|
||||
## Fix autobuild problems
|
||||
|
||||
On the [autobuilds page](https://curl.se/dev/builds.html) we show a
|
||||
collection of test results from the automatic curl build and tests that are
|
||||
performed by volunteers. Fixing compiler warnings and errors shown there is
|
||||
something we value greatly. Also, if you own or run systems or architectures
|
||||
that are not already tested in the autobuilds, we also appreciate more
|
||||
volunteers running builds automatically to help us keep curl portable.
|
||||
|
||||
## TODO items
|
||||
|
||||
Ideas for features and functions that we have considered worthwhile to
|
||||
implement and provide are kept in the
|
||||
[TODO](https://curl.se/docs/todo.html) file. Some of the ideas are
|
||||
rough. Some are well thought out. Some probably are not really suitable
|
||||
anymore.
|
||||
|
||||
Before you invest a lot of time on a TODO item, do bring it up for discussion
|
||||
on the mailing list. For discussion on applicability but also for ideas and
|
||||
brainstorming on specific ways to do the implementation etc.
|
||||
|
||||
## You decide
|
||||
|
||||
You can also come up with a completely new thing you think we should do. Or
|
||||
not do. Or fix. Or add to the project. You then either bring it to the mailing
|
||||
list first to see if people will shoot down the idea at once, or you bring a
|
||||
first draft of the idea as a pull request and take the discussion there around
|
||||
the specific implementation. Either way is fine.
|
||||
|
||||
## CONTRIBUTE
|
||||
|
||||
We offer [guidelines](https://curl.se/dev/contribute.html) that are
|
||||
suitable to be familiar with before you decide to contribute to curl. If
|
||||
you are used to open source development, you will probably not find many
|
||||
surprises there.
|
||||
@ -0,0 +1,432 @@
|
||||
How curl Became Like This
|
||||
=========================
|
||||
|
||||
Towards the end of 1996, Daniel Stenberg was spending time writing an IRC bot
|
||||
for an Amiga related channel on EFnet. He then came up with the idea to make
|
||||
currency-exchange calculations available to Internet Relay Chat (IRC)
|
||||
users. All the necessary data were published on the Web; he just needed to
|
||||
automate their retrieval.
|
||||
|
||||
1996
|
||||
----
|
||||
|
||||
On November 11, 1996 the Brazilian developer Rafael Sagula wrote and released
|
||||
HttpGet version 0.1.
|
||||
|
||||
Daniel extended this existing command-line open-source tool. After a few minor
|
||||
adjustments, it did just what he needed. The first release with Daniel's
|
||||
additions was 0.2, released on December 17, 1996. Daniel quickly became the
|
||||
new maintainer of the project.
|
||||
|
||||
1997
|
||||
----
|
||||
|
||||
HttpGet 0.3 was released in January 1997 and now it accepted HTTP URLs on the
|
||||
command line.
|
||||
|
||||
HttpGet 1.0 was released on April 8 1997 with brand new HTTP proxy support.
|
||||
|
||||
We soon found and fixed support for getting currencies over GOPHER. Once FTP
|
||||
download support was added, the name of the project was changed and urlget 2.0
|
||||
was released in August 1997. The http-only days were already passed.
|
||||
|
||||
Version 2.2 was released on August 14 1997 and introduced support to build for
|
||||
and run on Windows and Solaris.
|
||||
|
||||
November 24 1997: Version 3.1 added FTP upload support.
|
||||
|
||||
Version 3.5 added support for HTTP POST.
|
||||
|
||||
1998
|
||||
----
|
||||
|
||||
February 4: urlget 3.10
|
||||
|
||||
February 9: urlget 3.11
|
||||
|
||||
March 14: urlget 3.12 added proxy authentication.
|
||||
|
||||
The project slowly grew bigger. With upload capabilities, the name was once
|
||||
again misleading and a second name change was made. On March 20, 1998 curl 4
|
||||
was released. (The version numbering from the previous names was kept.)
|
||||
|
||||
(Unrelated to this project a company called Curl Corporation registered a US
|
||||
trademark on the name "CURL" on May 18 1998. That company had then already
|
||||
registered the curl.com domain back in November of the previous year. All this
|
||||
was revealed to us much later.)
|
||||
|
||||
SSL support was added, powered by the SSLeay library.
|
||||
|
||||
August: first announcement of curl on freshmeat.net.
|
||||
|
||||
October: with the curl 4.9 release and the introduction of cookie support,
|
||||
curl was no longer released under the GPL license. Now we are at 4000 lines of
|
||||
code, we switched over to the MPL license to restrict the effects of
|
||||
"copyleft".
|
||||
|
||||
November: configure script and reported successful compiles on several
|
||||
major operating systems. The never-quite-understood -F option was added and
|
||||
curl could now simulate quite a lot of a browser. TELNET support was added.
|
||||
|
||||
Curl 5 was released in December 1998 and introduced the first ever curl man
|
||||
page. People started making Linux RPM packages out of it.
|
||||
|
||||
1999
|
||||
----
|
||||
|
||||
January: DICT support added.
|
||||
|
||||
OpenSSL took over and SSLeay was abandoned.
|
||||
|
||||
May: first Debian package.
|
||||
|
||||
August: LDAP:// and FILE:// support added. The curl website gets 1300 visits
|
||||
weekly. Moved site to curl.haxx.nu.
|
||||
|
||||
September: Released curl 6.0. 15000 lines of code.
|
||||
|
||||
December 28: added the project on Sourceforge and started using its services
|
||||
for managing the project.
|
||||
|
||||
2000
|
||||
----
|
||||
|
||||
Spring: major internal overhaul to provide a suitable library interface.
|
||||
The first non-beta release was named 7.1 and arrived in August. This offered
|
||||
the easy interface and turned out to be the beginning of actually getting
|
||||
other software and programs to be based on and powered by libcurl. Almost
|
||||
20000 lines of code.
|
||||
|
||||
June: the curl site moves to "curl.haxx.se"
|
||||
|
||||
August, the curl website gets 4000 visits weekly.
|
||||
|
||||
The PHP guys adopted libcurl already the same month, when the first ever third
|
||||
party libcurl binding showed up. CURL has been a supported module in PHP since
|
||||
the release of PHP 4.0.2. This would soon get followers. More than 16
|
||||
different bindings exist at the time of this writing.
|
||||
|
||||
September: kerberos4 support was added.
|
||||
|
||||
November: started the work on a test suite for curl. It was later re-written
|
||||
from scratch again. The libcurl major SONAME number was set to 1.
|
||||
|
||||
2001
|
||||
----
|
||||
|
||||
January: Daniel released curl 7.5.2 under a new license again: MIT (or
|
||||
MPL). The MIT license is extremely liberal and can be combined with GPL
|
||||
in other projects. This would finally put an end to the "complaints" from
|
||||
people involved in GPLed projects that previously were prohibited from using
|
||||
libcurl while it was released under MPL only. (Due to the fact that MPL is
|
||||
deemed "GPL incompatible".)
|
||||
|
||||
March 22: curl supports HTTP 1.1 starting with the release of 7.7. This
|
||||
also introduced libcurl's ability to do persistent connections. 24000 lines of
|
||||
code. The libcurl major SONAME number was bumped to 2 due to this overhaul.
|
||||
The first experimental ftps:// support was added.
|
||||
|
||||
August: The curl website gets 8000 visits weekly. Curl Corporation contacted
|
||||
Daniel to discuss "the name issue". After Daniel's reply, they have never
|
||||
since got back in touch again.
|
||||
|
||||
September: libcurl 7.9 introduces cookie jar and `curl_formadd()`. During the
|
||||
forthcoming 7.9.x releases, we introduced the multi interface slowly and
|
||||
without many whistles.
|
||||
|
||||
September 25: curl (7.7.2) is bundled in Mac OS X (10.1) for the first time. It was
|
||||
already becoming more and more of a standard utility of Linux distributions
|
||||
and a regular in the BSD ports collections.
|
||||
|
||||
2002
|
||||
----
|
||||
|
||||
June: the curl website gets 13000 visits weekly. curl and libcurl is
|
||||
35000 lines of code. Reported successful compiles on more than 40 combinations
|
||||
of CPUs and operating systems.
|
||||
|
||||
To estimate the number of users of the curl tool or libcurl library is next to
|
||||
impossible. Around 5000 downloaded packages each week from the main site gives
|
||||
a hint, but the packages are mirrored extensively, bundled with numerous OS
|
||||
distributions and otherwise retrieved as part of other software.
|
||||
|
||||
October 1: with the release of curl 7.10 it is released under the MIT license
|
||||
only.
|
||||
|
||||
Starting with 7.10, curl verifies SSL server certificates by default.
|
||||
|
||||
2003
|
||||
----
|
||||
|
||||
January: Started working on the distributed curl tests. The autobuilds.
|
||||
|
||||
February: the curl site averages at 20000 visits weekly. At any given moment,
|
||||
there's an average of 3 people browsing the website.
|
||||
|
||||
Multiple new authentication schemes are supported: Digest (May), NTLM (June)
|
||||
and Negotiate (June).
|
||||
|
||||
November: curl 7.10.8 is released. 45000 lines of code. ~55000 unique visitors
|
||||
to the website. Five official web mirrors.
|
||||
|
||||
December: full-fledged SSL for FTP is supported.
|
||||
|
||||
2004
|
||||
----
|
||||
|
||||
January: curl 7.11.0 introduced large file support.
|
||||
|
||||
June: curl 7.12.0 introduced IDN support. 10 official web mirrors.
|
||||
|
||||
This release bumped the major SONAME to 3 due to the removal of the
|
||||
`curl_formparse()` function
|
||||
|
||||
August: Curl and libcurl 7.12.1
|
||||
|
||||
Public curl release number: 82
|
||||
Releases counted from the beginning: 109
|
||||
Available command line options: 96
|
||||
Available curl_easy_setopt() options: 120
|
||||
Number of public functions in libcurl: 36
|
||||
Amount of public website mirrors: 12
|
||||
Number of known libcurl bindings: 26
|
||||
|
||||
2005
|
||||
----
|
||||
|
||||
April: GnuTLS can now optionally be used for the secure layer when curl is
|
||||
built.
|
||||
|
||||
April: Added the multi_socket() API
|
||||
|
||||
September: TFTP support was added.
|
||||
|
||||
More than 100,000 unique visitors of the curl website. 25 mirrors.
|
||||
|
||||
December: security vulnerability: libcurl URL Buffer Overflow
|
||||
|
||||
2006
|
||||
----
|
||||
|
||||
January: We dropped support for Gopher. We found bugs in the implementation
|
||||
that turned out to have been introduced years ago, so with the conclusion that
|
||||
nobody had found out in all this time we removed it instead of fixing it.
|
||||
|
||||
March: security vulnerability: libcurl TFTP Packet Buffer Overflow
|
||||
|
||||
September: The major SONAME number for libcurl was bumped to 4 due to the
|
||||
removal of ftp third party transfer support.
|
||||
|
||||
November: Added SCP and SFTP support
|
||||
|
||||
2007
|
||||
----
|
||||
|
||||
February: Added support for the Mozilla NSS library to do the SSL/TLS stuff
|
||||
|
||||
July: security vulnerability: libcurl GnuTLS insufficient cert verification
|
||||
|
||||
2008
|
||||
----
|
||||
|
||||
November:
|
||||
|
||||
Command line options: 128
|
||||
curl_easy_setopt() options: 158
|
||||
Public functions in libcurl: 58
|
||||
Known libcurl bindings: 37
|
||||
Contributors: 683
|
||||
|
||||
145,000 unique visitors. >100 GB downloaded.
|
||||
|
||||
2009
|
||||
----
|
||||
|
||||
March: security vulnerability: libcurl Arbitrary File Access
|
||||
|
||||
April: added CMake support
|
||||
|
||||
August: security vulnerability: libcurl embedded zero in cert name
|
||||
|
||||
December: Added support for IMAP, POP3 and SMTP
|
||||
|
||||
2010
|
||||
----
|
||||
|
||||
January: Added support for RTSP
|
||||
|
||||
February: security vulnerability: libcurl data callback excessive length
|
||||
|
||||
March: The project switched over to use git (hosted by GitHub) instead of CVS
|
||||
for source code control
|
||||
|
||||
May: Added support for RTMP
|
||||
|
||||
Added support for PolarSSL to do the SSL/TLS stuff
|
||||
|
||||
August:
|
||||
|
||||
Public curl releases: 117
|
||||
Command line options: 138
|
||||
curl_easy_setopt() options: 180
|
||||
Public functions in libcurl: 58
|
||||
Known libcurl bindings: 39
|
||||
Contributors: 808
|
||||
|
||||
Gopher support added (re-added actually, see January 2006)
|
||||
|
||||
2011
|
||||
----
|
||||
|
||||
February: added support for the axTLS backend
|
||||
|
||||
April: added the cyassl backend (later renamed to WolfSSL)
|
||||
|
||||
2012
|
||||
----
|
||||
|
||||
July: Added support for Schannel (native Windows TLS backend) and Darwin SSL
|
||||
(Native Mac OS X and iOS TLS backend).
|
||||
|
||||
Supports Metalink
|
||||
|
||||
October: SSH-agent support.
|
||||
|
||||
2013
|
||||
----
|
||||
|
||||
February: Cleaned up internals to always uses the "multi" non-blocking
|
||||
approach internally and only expose the blocking API with a wrapper.
|
||||
|
||||
September: First small steps on supporting HTTP/2 with nghttp2.
|
||||
|
||||
October: Removed krb4 support.
|
||||
|
||||
December: Happy eyeballs.
|
||||
|
||||
2014
|
||||
----
|
||||
|
||||
March: first real release supporting HTTP/2
|
||||
|
||||
September: Website had 245,000 unique visitors and served 236GB data
|
||||
|
||||
SMB and SMBS support
|
||||
|
||||
2015
|
||||
----
|
||||
|
||||
June: support for multiplexing with HTTP/2
|
||||
|
||||
August: support for HTTP/2 server push
|
||||
|
||||
December: Public Suffix List
|
||||
|
||||
2016
|
||||
----
|
||||
|
||||
January: the curl tool defaults to HTTP/2 for HTTPS URLs
|
||||
|
||||
December: curl 7.52.0 introduced support for HTTPS-proxy!
|
||||
|
||||
First TLS 1.3 support
|
||||
|
||||
2017
|
||||
----
|
||||
|
||||
July: OSS-Fuzz started fuzzing libcurl
|
||||
|
||||
September: Added Multi-SSL support
|
||||
|
||||
The website serves 3100 GB/month
|
||||
|
||||
Public curl releases: 169
|
||||
Command line options: 211
|
||||
curl_easy_setopt() options: 249
|
||||
Public functions in libcurl: 74
|
||||
Contributors: 1609
|
||||
|
||||
October: SSLKEYLOGFILE support, new MIME API
|
||||
|
||||
October: Daniel received the Polhem Prize for his work on curl
|
||||
|
||||
November: brotli
|
||||
|
||||
2018
|
||||
----
|
||||
|
||||
January: new SSH backend powered by libssh
|
||||
|
||||
March: starting with the 1803 release of Windows 10, curl is shipped bundled
|
||||
with Microsoft's operating system.
|
||||
|
||||
July: curl shows headers using bold type face
|
||||
|
||||
October: added DNS-over-HTTPS (DoH) and the URL API
|
||||
|
||||
MesaLink is a new supported TLS backend
|
||||
|
||||
libcurl now does HTTP/2 (and multiplexing) by default on HTTPS URLs
|
||||
|
||||
curl and libcurl are installed in an estimated 5 *billion* instances
|
||||
world-wide.
|
||||
|
||||
October 31: Curl and libcurl 7.62.0
|
||||
|
||||
Public curl releases: 177
|
||||
Command line options: 219
|
||||
curl_easy_setopt() options: 261
|
||||
Public functions in libcurl: 80
|
||||
Contributors: 1808
|
||||
|
||||
December: removed axTLS support
|
||||
|
||||
2019
|
||||
----
|
||||
|
||||
March: added experimental alt-svc support
|
||||
|
||||
August: the first HTTP/3 requests with curl.
|
||||
|
||||
September: 7.66.0 is released and the tool offers parallel downloads
|
||||
|
||||
2020
|
||||
----
|
||||
|
||||
curl and libcurl are installed in an estimated 10 *billion* instances
|
||||
world-wide.
|
||||
|
||||
January: added BearSSL support
|
||||
|
||||
March: removed support for PolarSSL, added wolfSSH support
|
||||
|
||||
April: experimental MQTT support
|
||||
|
||||
August: zstd support
|
||||
|
||||
November: the website moves to curl.se. The website serves 10TB data monthly.
|
||||
|
||||
December: alt-svc support
|
||||
|
||||
2021
|
||||
----
|
||||
|
||||
February 3: curl 7.75.0 ships with support for Hyper as an HTTP backend
|
||||
|
||||
March 31: curl 7.76.0 ships with support for rustls
|
||||
|
||||
July: HSTS is supported
|
||||
|
||||
2022
|
||||
----
|
||||
|
||||
March: added --json, removed mesalink support
|
||||
|
||||
Public curl releases: 206
|
||||
Command line options: 245
|
||||
curl_easy_setopt() options: 295
|
||||
Public functions in libcurl: 86
|
||||
Contributors: 2601
|
||||
|
||||
The curl.se website serves 16,500 GB/month over 462M requests, the
|
||||
official docker image has been pulled 4,098,015,431 times.
|
||||
@ -0,0 +1,42 @@
|
||||
# HSTS support
|
||||
|
||||
HTTP Strict-Transport-Security. Added as experimental in curl
|
||||
7.74.0. Supported "for real" since 7.77.0.
|
||||
|
||||
## Standard
|
||||
|
||||
[HTTP Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc6797)
|
||||
|
||||
## Behavior
|
||||
|
||||
libcurl features an in-memory cache for HSTS hosts, so that subsequent
|
||||
HTTP-only requests to a host name present in the cache will get internally
|
||||
"redirected" to the HTTPS version.
|
||||
|
||||
## `curl_easy_setopt()` options:
|
||||
|
||||
- `CURLOPT_HSTS_CTRL` - enable HSTS for this easy handle
|
||||
- `CURLOPT_HSTS` - specify file name where to store the HSTS cache on close
|
||||
(and possibly read from at startup)
|
||||
|
||||
## curl command line options
|
||||
|
||||
- `--hsts [filename]` - enable HSTS, use the file as HSTS cache. If filename
|
||||
is `""` (no length) then no file will be used, only in-memory cache.
|
||||
|
||||
## HSTS cache file format
|
||||
|
||||
Lines starting with `#` are ignored.
|
||||
|
||||
For each hsts entry:
|
||||
|
||||
[host name] "YYYYMMDD HH:MM:SS"
|
||||
|
||||
The `[host name]` is dot-prefixed if it includes subdomains.
|
||||
|
||||
The time stamp is when the entry expires.
|
||||
|
||||
## Possible future additions
|
||||
|
||||
- `CURLOPT_HSTS_PRELOAD` - provide a set of HSTS host names to load first
|
||||
- ability to save to something else than a file
|
||||
@ -0,0 +1,145 @@
|
||||
# HTTP Cookies
|
||||
|
||||
## Cookie overview
|
||||
|
||||
Cookies are `name=contents` pairs that an HTTP server tells the client to
|
||||
hold and then the client sends back those to the server on subsequent
|
||||
requests to the same domains and paths for which the cookies were set.
|
||||
|
||||
Cookies are either "session cookies" which typically are forgotten when the
|
||||
session is over which is often translated to equal when browser quits, or
|
||||
the cookies are not session cookies they have expiration dates after which
|
||||
the client will throw them away.
|
||||
|
||||
Cookies are set to the client with the Set-Cookie: header and are sent to
|
||||
servers with the Cookie: header.
|
||||
|
||||
For a long time, the only spec explaining how to use cookies was the
|
||||
original [Netscape spec from 1994](https://curl.se/rfc/cookie_spec.html).
|
||||
|
||||
In 2011, [RFC6265](https://www.ietf.org/rfc/rfc6265.txt) was finally
|
||||
published and details how cookies work within HTTP. In 2016, an update which
|
||||
added support for prefixes was
|
||||
[proposed](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-prefixes-00),
|
||||
and in 2017, another update was
|
||||
[drafted](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-alone-01)
|
||||
to deprecate modification of 'secure' cookies from non-secure origins. Both
|
||||
of these drafts have been incorporated into a proposal to
|
||||
[replace](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-11)
|
||||
RFC6265. Cookie prefixes and secure cookie modification protection has been
|
||||
implemented by curl.
|
||||
|
||||
curl considers `http://localhost` to be a *secure context*, meaning that it
|
||||
will allow and use cookies marked with the `secure` keyword even when done
|
||||
over plain HTTP for this host. curl does this to match how popular browsers
|
||||
work with secure cookies.
|
||||
|
||||
## Cookies saved to disk
|
||||
|
||||
Netscape once created a file format for storing cookies on disk so that they
|
||||
would survive browser restarts. curl adopted that file format to allow
|
||||
sharing the cookies with browsers, only to see browsers move away from that
|
||||
format. Modern browsers no longer use it, while curl still does.
|
||||
|
||||
The Netscape cookie file format stores one cookie per physical line in the
|
||||
file with a bunch of associated meta data, each field separated with
|
||||
TAB. That file is called the cookie jar in curl terminology.
|
||||
|
||||
When libcurl saves a cookie jar, it creates a file header of its own in
|
||||
which there is a URL mention that will link to the web version of this
|
||||
document.
|
||||
|
||||
## Cookie file format
|
||||
|
||||
The cookie file format is text based and stores one cookie per line. Lines
|
||||
that start with `#` are treated as comments.
|
||||
|
||||
Each line that specifies a single cookie consists of seven text fields
|
||||
separated with TAB characters. A valid line must end with a newline
|
||||
character.
|
||||
|
||||
### Fields in the file
|
||||
|
||||
Field number, what type and example data and the meaning of it:
|
||||
|
||||
0. string `example.com` - the domain name
|
||||
1. boolean `FALSE` - include subdomains
|
||||
2. string `/foobar/` - path
|
||||
3. boolean `TRUE` - send/receive over HTTPS only
|
||||
4. number `1462299217` - expires at - seconds since Jan 1st 1970, or 0
|
||||
5. string `person` - name of the cookie
|
||||
6. string `daniel` - value of the cookie
|
||||
|
||||
## Cookies with curl the command line tool
|
||||
|
||||
curl has a full cookie "engine" built in. If you just activate it, you can
|
||||
have curl receive and send cookies exactly as mandated in the specs.
|
||||
|
||||
Command line options:
|
||||
|
||||
`-b, --cookie`
|
||||
|
||||
tell curl a file to read cookies from and start the cookie engine, or if it
|
||||
is not a file it will pass on the given string. `-b name=var` works and so
|
||||
does `-b cookiefile`.
|
||||
|
||||
`-j, --junk-session-cookies`
|
||||
|
||||
when used in combination with -b, it will skip all "session cookies" on load
|
||||
so as to appear to start a new cookie session.
|
||||
|
||||
`-c, --cookie-jar`
|
||||
|
||||
tell curl to start the cookie engine and write cookies to the given file
|
||||
after the request(s)
|
||||
|
||||
## Cookies with libcurl
|
||||
|
||||
libcurl offers several ways to enable and interface the cookie engine. These
|
||||
options are the ones provided by the native API. libcurl bindings may offer
|
||||
access to them using other means.
|
||||
|
||||
`CURLOPT_COOKIE`
|
||||
|
||||
Is used when you want to specify the exact contents of a cookie header to
|
||||
send to the server.
|
||||
|
||||
`CURLOPT_COOKIEFILE`
|
||||
|
||||
Tell libcurl to activate the cookie engine, and to read the initial set of
|
||||
cookies from the given file. Read-only.
|
||||
|
||||
`CURLOPT_COOKIEJAR`
|
||||
|
||||
Tell libcurl to activate the cookie engine, and when the easy handle is
|
||||
closed save all known cookies to the given cookie jar file. Write-only.
|
||||
|
||||
`CURLOPT_COOKIELIST`
|
||||
|
||||
Provide detailed information about a single cookie to add to the internal
|
||||
storage of cookies. Pass in the cookie as an HTTP header with all the
|
||||
details set, or pass in a line from a Netscape cookie file. This option can
|
||||
also be used to flush the cookies etc.
|
||||
|
||||
`CURLOPT_COOKIESESSION`
|
||||
|
||||
Tell libcurl to ignore all cookies it is about to load that are session
|
||||
cookies.
|
||||
|
||||
`CURLINFO_COOKIELIST`
|
||||
|
||||
Extract cookie information from the internal cookie storage as a linked
|
||||
list.
|
||||
|
||||
## Cookies with JavaScript
|
||||
|
||||
These days a lot of the web is built up by JavaScript. The web browser loads
|
||||
complete programs that render the page you see. These JavaScript programs
|
||||
can also set and access cookies.
|
||||
|
||||
Since curl and libcurl are plain HTTP clients without any knowledge of or
|
||||
capability to handle JavaScript, such cookies will not be detected or used.
|
||||
|
||||
Often, if you want to mimic what a browser does on such websites, you can
|
||||
record web browser HTTP traffic when using such a site and then repeat the
|
||||
cookie operations using curl or libcurl.
|
||||
@ -0,0 +1,102 @@
|
||||
HTTP/2 with curl
|
||||
================
|
||||
|
||||
[HTTP/2 Spec](https://www.rfc-editor.org/rfc/rfc7540.txt)
|
||||
[http2 explained](https://daniel.haxx.se/http2/)
|
||||
|
||||
Build prerequisites
|
||||
-------------------
|
||||
- nghttp2
|
||||
- OpenSSL, libressl, BoringSSL, NSS, GnuTLS, mbedTLS, wolfSSL or Schannel
|
||||
with a new enough version.
|
||||
|
||||
[nghttp2](https://nghttp2.org/)
|
||||
-------------------------------
|
||||
|
||||
libcurl uses this 3rd party library for the low level protocol handling
|
||||
parts. The reason for this is that HTTP/2 is much more complex at that layer
|
||||
than HTTP/1.1 (which we implement on our own) and that nghttp2 is an already
|
||||
existing and well functional library.
|
||||
|
||||
We require at least version 1.12.0.
|
||||
|
||||
Over an http:// URL
|
||||
-------------------
|
||||
|
||||
If `CURLOPT_HTTP_VERSION` is set to `CURL_HTTP_VERSION_2_0`, libcurl will
|
||||
include an upgrade header in the initial request to the host to allow
|
||||
upgrading to HTTP/2.
|
||||
|
||||
Possibly we can later introduce an option that will cause libcurl to fail if
|
||||
not possible to upgrade. Possibly we introduce an option that makes libcurl
|
||||
use HTTP/2 at once over http://
|
||||
|
||||
Over an https:// URL
|
||||
--------------------
|
||||
|
||||
If `CURLOPT_HTTP_VERSION` is set to `CURL_HTTP_VERSION_2_0`, libcurl will use
|
||||
ALPN to negotiate which protocol to continue with. Possibly introduce an
|
||||
option that will cause libcurl to fail if not possible to use HTTP/2.
|
||||
|
||||
`CURL_HTTP_VERSION_2TLS` was added in 7.47.0 as a way to ask libcurl to prefer
|
||||
HTTP/2 for HTTPS but stick to 1.1 by default for plain old HTTP connections.
|
||||
|
||||
ALPN is the TLS extension that HTTP/2 is expected to use.
|
||||
|
||||
`CURLOPT_SSL_ENABLE_ALPN` is offered to allow applications to explicitly
|
||||
disable ALPN.
|
||||
|
||||
Multiplexing
|
||||
------------
|
||||
|
||||
Starting in 7.43.0, libcurl fully supports HTTP/2 multiplexing, which is the
|
||||
term for doing multiple independent transfers over the same physical TCP
|
||||
connection.
|
||||
|
||||
To take advantage of multiplexing, you need to use the multi interface and set
|
||||
`CURLMOPT_PIPELINING` to `CURLPIPE_MULTIPLEX`. With that bit set, libcurl will
|
||||
attempt to re-use existing HTTP/2 connections and just add a new stream over
|
||||
that when doing subsequent parallel requests.
|
||||
|
||||
While libcurl sets up a connection to an HTTP server there is a period during
|
||||
which it does not know if it can pipeline or do multiplexing and if you add
|
||||
new transfers in that period, libcurl will default to start new connections
|
||||
for those transfers. With the new option `CURLOPT_PIPEWAIT` (added in 7.43.0),
|
||||
you can ask that a transfer should rather wait and see in case there's a
|
||||
connection for the same host in progress that might end up being possible to
|
||||
multiplex on. It favors keeping the number of connections low to the cost of
|
||||
slightly longer time to first byte transferred.
|
||||
|
||||
Applications
|
||||
------------
|
||||
|
||||
We hide HTTP/2's binary nature and convert received HTTP/2 traffic to headers
|
||||
in HTTP 1.1 style. This allows applications to work unmodified.
|
||||
|
||||
curl tool
|
||||
---------
|
||||
|
||||
curl offers the `--http2` command line option to enable use of HTTP/2.
|
||||
|
||||
curl offers the `--http2-prior-knowledge` command line option to enable use of
|
||||
HTTP/2 without HTTP/1.1 Upgrade.
|
||||
|
||||
Since 7.47.0, the curl tool enables HTTP/2 by default for HTTPS connections.
|
||||
|
||||
curl tool limitations
|
||||
---------------------
|
||||
|
||||
The command line tool does not support HTTP/2 server push. It supports
|
||||
multiplexing when the parallel transfer option is used.
|
||||
|
||||
HTTP Alternative Services
|
||||
-------------------------
|
||||
|
||||
Alt-Svc is an extension with a corresponding frame (ALTSVC) in HTTP/2 that
|
||||
tells the client about an alternative "route" to the same content for the same
|
||||
origin server that you get the response from. A browser or long-living client
|
||||
can use that hint to create a new connection asynchronously. For libcurl, we
|
||||
may introduce a way to bring such clues to the application and/or let a
|
||||
subsequent request use the alternate route automatically.
|
||||
|
||||
[Detailed in RFC 7838](https://datatracker.ietf.org/doc/html/rfc7838)
|
||||
@ -0,0 +1,345 @@
|
||||
# HTTP3 (and QUIC)
|
||||
|
||||
## Resources
|
||||
|
||||
[HTTP/3 Explained](https://http3-explained.haxx.se/en/) - the online free
|
||||
book describing the protocols involved.
|
||||
|
||||
[quicwg.org](https://quicwg.org/) - home of the official protocol drafts
|
||||
|
||||
## QUIC libraries
|
||||
|
||||
QUIC libraries we are experimenting with:
|
||||
|
||||
[ngtcp2](https://github.com/ngtcp2/ngtcp2)
|
||||
|
||||
[quiche](https://github.com/cloudflare/quiche)
|
||||
|
||||
[msh3](https://github.com/nibanks/msh3) (with [msquic](https://github.com/microsoft/msquic))
|
||||
|
||||
## Experimental
|
||||
|
||||
HTTP/3 and QUIC support in curl is considered **EXPERIMENTAL** until further
|
||||
notice. It needs to be enabled at build-time.
|
||||
|
||||
Further development and tweaking of the HTTP/3 support in curl will happen in
|
||||
the master branch using pull-requests, just like ordinary changes.
|
||||
|
||||
To fix before we remove the experimental label:
|
||||
|
||||
- working multiplexing and GTFO handling
|
||||
- fallback or another flexible way to go (back to) h1/h2 if h3 fails
|
||||
- enough test cases to verify basic HTTP/3 functionality
|
||||
- no "important" bugs left on HTTP/3
|
||||
- it's fine to "leave" individual backends as experimental if necessary
|
||||
|
||||
# ngtcp2 version
|
||||
|
||||
## Build with OpenSSL
|
||||
|
||||
Build (patched) OpenSSL
|
||||
|
||||
% git clone --depth 1 -b openssl-3.0.8+quic https://github.com/quictls/openssl
|
||||
% cd openssl
|
||||
% ./config enable-tls1_3 --prefix=<somewhere1>
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build nghttp3
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/nghttp3
|
||||
% cd nghttp3
|
||||
% autoreconf -fi
|
||||
% ./configure --prefix=<somewhere2> --enable-lib-only
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build ngtcp2
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/ngtcp2
|
||||
% cd ngtcp2
|
||||
% autoreconf -fi
|
||||
% ./configure PKG_CONFIG_PATH=<somewhere1>/lib/pkgconfig:<somewhere2>/lib/pkgconfig LDFLAGS="-Wl,-rpath,<somewhere1>/lib" --prefix=<somewhere3> --enable-lib-only
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build curl
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% LDFLAGS="-Wl,-rpath,<somewhere1>/lib" ./configure --with-openssl=<somewhere1> --with-nghttp3=<somewhere2> --with-ngtcp2=<somewhere3>
|
||||
% make
|
||||
% make install
|
||||
|
||||
For OpenSSL 3.0.0 or later builds on Linux for x86_64 architecture, substitute all occurrences of "/lib" with "/lib64"
|
||||
|
||||
## Build with GnuTLS
|
||||
|
||||
Build GnuTLS
|
||||
|
||||
% git clone --depth 1 https://gitlab.com/gnutls/gnutls.git
|
||||
% cd gnutls
|
||||
% ./bootstrap
|
||||
% ./configure --prefix=<somewhere1>
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build nghttp3
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/nghttp3
|
||||
% cd nghttp3
|
||||
% autoreconf -fi
|
||||
% ./configure --prefix=<somewhere2> --enable-lib-only
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build ngtcp2
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/ngtcp2
|
||||
% cd ngtcp2
|
||||
% autoreconf -fi
|
||||
% ./configure PKG_CONFIG_PATH=<somewhere1>/lib/pkgconfig:<somewhere2>/lib/pkgconfig LDFLAGS="-Wl,-rpath,<somewhere1>/lib" --prefix=<somewhere3> --enable-lib-only --with-gnutls
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build curl
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% ./configure --with-gnutls=<somewhere1> --with-nghttp3=<somewhere2> --with-ngtcp2=<somewhere3>
|
||||
% make
|
||||
% make install
|
||||
|
||||
## Build with wolfSSL
|
||||
|
||||
Build wolfSSL
|
||||
|
||||
% git clone https://github.com/wolfSSL/wolfssl.git
|
||||
% cd wolfssl
|
||||
% autoreconf -fi
|
||||
% ./configure --prefix=<somewhere1> --enable-quic --enable-session-ticket --enable-earlydata --enable-psk --enable-harden --enable-altcertchains
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build nghttp3
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/nghttp3
|
||||
% cd nghttp3
|
||||
% autoreconf -fi
|
||||
% ./configure --prefix=<somewhere2> --enable-lib-only
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build ngtcp2
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/ngtcp2/ngtcp2
|
||||
% cd ngtcp2
|
||||
% autoreconf -fi
|
||||
% ./configure PKG_CONFIG_PATH=<somewhere1>/lib/pkgconfig:<somewhere2>/lib/pkgconfig LDFLAGS="-Wl,-rpath,<somewhere1>/lib" --prefix=<somewhere3> --enable-lib-only --with-wolfssl
|
||||
% make
|
||||
% make install
|
||||
|
||||
Build curl
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% ./configure --with-wolfssl=<somewhere1> --with-nghttp3=<somewhere2> --with-ngtcp2=<somewhere3>
|
||||
% make
|
||||
% make install
|
||||
|
||||
# quiche version
|
||||
|
||||
## build
|
||||
|
||||
Build quiche and BoringSSL:
|
||||
|
||||
% git clone --recursive https://github.com/cloudflare/quiche
|
||||
% cd quiche
|
||||
% cargo build --package quiche --release --features ffi,pkg-config-meta,qlog
|
||||
% mkdir quiche/deps/boringssl/src/lib
|
||||
% ln -vnf $(find target/release -name libcrypto.a -o -name libssl.a) quiche/deps/boringssl/src/lib/
|
||||
|
||||
Build curl:
|
||||
|
||||
% cd ..
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% ./configure LDFLAGS="-Wl,-rpath,$PWD/../quiche/target/release" --with-openssl=$PWD/../quiche/quiche/deps/boringssl/src --with-quiche=$PWD/../quiche/target/release
|
||||
% make
|
||||
% make install
|
||||
|
||||
If `make install` results in `Permission denied` error, you will need to prepend it with `sudo`.
|
||||
|
||||
# msh3 (msquic) version
|
||||
|
||||
## Build Linux (with quictls fork of OpenSSL)
|
||||
|
||||
Build msh3:
|
||||
|
||||
% git clone -b v0.6.0 --depth 1 --recursive https://github.com/nibanks/msh3
|
||||
% cd msh3 && mkdir build && cd build
|
||||
% cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
|
||||
% cmake --build .
|
||||
% cmake --install .
|
||||
|
||||
Build curl:
|
||||
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% ./configure LDFLAGS="-Wl,-rpath,/usr/local/lib" --with-msh3=/usr/local --with-openssl
|
||||
% make
|
||||
% make install
|
||||
|
||||
Run from `/usr/local/bin/curl`.
|
||||
|
||||
## Build Windows
|
||||
|
||||
Build msh3:
|
||||
|
||||
% git clone -b v0.6.0 --depth 1 --recursive https://github.com/nibanks/msh3
|
||||
% cd msh3 && mkdir build && cd build
|
||||
% cmake -G 'Visual Studio 17 2022' -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
|
||||
% cmake --build . --config Release
|
||||
% cmake --install . --config Release
|
||||
|
||||
**Note** - On Windows, Schannel will be used for TLS support by default. If
|
||||
you with to use (the quictls fork of) OpenSSL, specify the `-DQUIC_TLS=openssl`
|
||||
option to the generate command above. Also note that OpenSSL brings with it an
|
||||
additional set of build dependencies not specified here.
|
||||
|
||||
Build curl (in [Visual Studio Command prompt](../winbuild/README.md#open-a-command-prompt)):
|
||||
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl/winbuild
|
||||
% nmake /f Makefile.vc mode=dll WITH_MSH3=dll MSH3_PATH="C:/Program Files/msh3" MACHINE=x64
|
||||
|
||||
**Note** - If you encounter a build error with `tool_hugehelp.c` being missing,
|
||||
rename `tool_hugehelp.c.cvs` in the same directory to `tool_hugehelp.c` and
|
||||
then run `nmake` again.
|
||||
|
||||
Run in the `C:/Program Files/msh3/lib` directory, copy `curl.exe` to that
|
||||
directory, or copy `msquic.dll` and `msh3.dll` from that directory to the
|
||||
`curl.exe` directory. For example:
|
||||
|
||||
% C:\Program Files\msh3\lib> F:\curl\builds\libcurl-vc-x64-release-dll-ipv6-sspi-schannel-msh3\bin\curl.exe --http3 https://www.google.com
|
||||
|
||||
# `--http3`
|
||||
|
||||
Use only HTTP/3:
|
||||
|
||||
curl --http3-only https://nghttp2.org:4433/
|
||||
|
||||
Use HTTP/3 with fallback to HTTP/2 or HTTP/1.1 (see "HTTPS eyeballing" below):
|
||||
|
||||
curl --http3 https://nghttp2.org:4433/
|
||||
|
||||
Upgrade via Alt-Svc:
|
||||
|
||||
curl --alt-svc altsvc.cache https://quic.aiortc.org/
|
||||
|
||||
See this [list of public HTTP/3 servers](https://bagder.github.io/HTTP3-test/)
|
||||
|
||||
### HTTPS eyeballing
|
||||
|
||||
With option `--http3` curl will attempt earlier HTTP versions as well should the connect
|
||||
attempt via HTTP/3 not succeed "fast enough". This strategy is similar to IPv4/6 happy
|
||||
eyeballing where the alternate address family is used in parallel after a short delay.
|
||||
|
||||
The IPv4/6 eyeballing has a default of 200ms and you may override that via `--happy-eyeballs-timeout-ms value`.
|
||||
Since HTTP/3 is still relatively new, we decided to use this timeout also for the HTTP eyeballing - with a slight twist.
|
||||
|
||||
The `happy-eyeballs-timeout-ms` value is the **hard** timeout, meaning after that time expired, a TLS connection is opened in addition to negotiate HTTP/2 or HTTP/1.1. At half of that value - currently - is the **soft** timeout. The soft timeout fires, when there has been **no data at all** seen from the server on the HTTP/3 connection.
|
||||
|
||||
So, without you specifying anything, the hard timeout is 200ms and the soft is 100ms:
|
||||
|
||||
* Ideally, the whole QUIC handshake happens and curl has a HTTP/3 connection in less than 100ms.
|
||||
* When QUIC is not supported (or UDP does not work for this network path), no reply is seen and the HTTP/2 TLS+TCP connection starts 100ms later.
|
||||
* In the worst case, UDP replies start before 100ms, but drag on. This will start the TLS+TCP connection after 200ms.
|
||||
* When the QUIC handshake fails, the TLS+TCP connection is attempted right away. For example, when the QUIC server presents the wrong certificate.
|
||||
|
||||
The whole transfer only fails, when **both** QUIC and TLS+TCP fail to handshake or time out.
|
||||
|
||||
Note that all this happens in addition to IP version happy eyeballing. If the name resolution for the server gives more than one IP address, curl will try all those until one succeeds - just as with all other protocols. And if those IP addresses contain both IPv6 and IPv4, those attempts will happen, delayed, in parallel (the actual eyeballing).
|
||||
|
||||
## Known Bugs
|
||||
|
||||
Check out the [list of known HTTP3 bugs](https://curl.se/docs/knownbugs.html#HTTP3).
|
||||
|
||||
# HTTP/3 Test server
|
||||
|
||||
This is not advice on how to run anything in production. This is for
|
||||
development and experimenting.
|
||||
|
||||
## Prerequisite(s)
|
||||
|
||||
An existing local HTTP/1.1 server that hosts files. Preferably also a few huge
|
||||
ones. You can easily create huge local files like `truncate -s=8G 8GB` - they
|
||||
are huge but do not occupy that much space on disk since they are just big
|
||||
holes.
|
||||
|
||||
In my Debian setup I just installed **apache2**. It runs on port 80 and has a
|
||||
document root in `/var/www/html`. I can get the 8GB file from it with `curl
|
||||
localhost/8GB -o dev/null`
|
||||
|
||||
In this description we setup and run an HTTP/3 reverse-proxy in front of the
|
||||
HTTP/1 server.
|
||||
|
||||
## Setup
|
||||
|
||||
You can select either or both of these server solutions.
|
||||
|
||||
### nghttpx
|
||||
|
||||
Get, build and install **quictls**, **nghttp3** and **ngtcp2** as described
|
||||
above.
|
||||
|
||||
Get, build and install **nghttp2**:
|
||||
|
||||
git clone https://github.com/nghttp2/nghttp2.git
|
||||
cd nghttp2
|
||||
autoreconf -fi
|
||||
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/daniel/build-quictls/lib/pkgconfig:/home/daniel/build-nghttp3/lib/pkgconfig:/home/daniel/build-ngtcp2/lib/pkgconfig LDFLAGS=-L/home/daniel/build-quictls/lib CFLAGS=-I/home/daniel/build-quictls/include ./configure --enable-maintainer-mode --prefix=/home/daniel/build-nghttp2 --disable-shared --enable-app --enable-http3 --without-jemalloc --without-libxml2 --without-systemd
|
||||
make && make install
|
||||
|
||||
Run the local h3 server on port 9443, make it proxy all traffic through to
|
||||
HTTP/1 on localhost port 80. For local toying, we can just use the test cert
|
||||
that exists in curl's test dir.
|
||||
|
||||
CERT=$CURLSRC/tests/stunnel.pem
|
||||
$HOME/bin/nghttpx $CERT $CERT --backend=localhost,80 \
|
||||
--frontend="localhost,9443;quic"
|
||||
|
||||
### Caddy
|
||||
|
||||
[Install Caddy](https://caddyserver.com/docs/install). For easiest use, the binary
|
||||
should be either in your PATH or your current directory.
|
||||
|
||||
Create a `Caddyfile` with the following content:
|
||||
~~~
|
||||
localhost:7443 {
|
||||
respond "Hello, world! You're using {http.request.proto}"
|
||||
}
|
||||
~~~
|
||||
|
||||
Then run Caddy:
|
||||
|
||||
./caddy start
|
||||
|
||||
Making requests to `https://localhost:7443` should tell you which protocol is being used.
|
||||
|
||||
You can change the hard-coded response to something more useful by replacing `respond`
|
||||
with `reverse_proxy` or `file_server`, for example: `reverse_proxy localhost:80`
|
||||
@ -0,0 +1,73 @@
|
||||
# Hyper
|
||||
|
||||
Hyper is a separate HTTP library written in Rust. curl can be told to use this
|
||||
library as a backend to deal with HTTP.
|
||||
|
||||
## Experimental!
|
||||
|
||||
Hyper support in curl is considered **EXPERIMENTAL** until further notice. It
|
||||
needs to be explicitly enabled at build-time.
|
||||
|
||||
Further development and tweaking of the Hyper backend support in curl will
|
||||
happen in the master branch using pull-requests, just like ordinary
|
||||
changes.
|
||||
|
||||
## Hyper version
|
||||
|
||||
The C API for Hyper is brand new and is still under development.
|
||||
|
||||
## build curl with hyper
|
||||
|
||||
Since March 3 2022, hyper needs the nightly rustc to build, which you may need
|
||||
to install first with:
|
||||
|
||||
% rustup toolchain install nightly
|
||||
|
||||
Then build hyper and enable its C API like this:
|
||||
|
||||
% git clone https://github.com/hyperium/hyper
|
||||
% cd hyper
|
||||
% RUSTFLAGS="--cfg hyper_unstable_ffi" cargo +nightly rustc --features client,http1,http2,ffi -Z unstable-options --crate-type cdylib
|
||||
|
||||
Build curl to use hyper's C API:
|
||||
|
||||
% git clone https://github.com/curl/curl
|
||||
% cd curl
|
||||
% autoreconf -fi
|
||||
% ./configure --with-hyper=<hyper dir>
|
||||
% make
|
||||
|
||||
# using Hyper internally
|
||||
|
||||
Hyper is a low level HTTP transport library. curl itself provides all HTTP
|
||||
headers and Hyper provides all received headers back to curl.
|
||||
|
||||
Therefore, most of the "header logic" in curl as in responding to and acting
|
||||
on specific input and output headers are done the same way in curl code.
|
||||
|
||||
The API in Hyper delivers received HTTP headers as (cleaned up) name=value
|
||||
pairs, making it impossible for curl to know the exact byte representation
|
||||
over the wire with Hyper.
|
||||
|
||||
## Limitations
|
||||
|
||||
The hyper backend does not support
|
||||
|
||||
- `CURLOPT_IGNORE_CONTENT_LENGTH`
|
||||
- `--raw` and disabling `CURLOPT_HTTP_TRANSFER_DECODING`
|
||||
- RTSP
|
||||
- hyper is much stricter about what HTTP header contents it allows
|
||||
- HTTP/0.9
|
||||
- HTTP/2 upgrade using HTTP:// URLs. Aka 'h2c'
|
||||
|
||||
## Remaining issues
|
||||
|
||||
This backend is still not feature complete with the native backend. Areas that
|
||||
still need attention and verification include:
|
||||
|
||||
- multiplexed HTTP/2
|
||||
- h2 Upgrade:
|
||||
- pausing transfers
|
||||
- receiving HTTP/1 trailers
|
||||
- sending HTTP/1 trailers
|
||||
|
||||
@ -0,0 +1,606 @@
|
||||
# how to install curl and libcurl
|
||||
|
||||
## Installing Binary Packages
|
||||
|
||||
Lots of people download binary distributions of curl and libcurl. This
|
||||
document does not describe how to install curl or libcurl using such a binary
|
||||
package. This document describes how to compile, build and install curl and
|
||||
libcurl from source code.
|
||||
|
||||
## Building using vcpkg
|
||||
|
||||
You can download and install curl and libcurl using the [vcpkg](https://github.com/Microsoft/vcpkg/) dependency manager:
|
||||
|
||||
git clone https://github.com/Microsoft/vcpkg.git
|
||||
cd vcpkg
|
||||
./bootstrap-vcpkg.sh
|
||||
./vcpkg integrate install
|
||||
vcpkg install curl[tool]
|
||||
|
||||
The curl port in vcpkg is kept up to date by Microsoft team members and
|
||||
community contributors. If the version is out of date, please [create an issue
|
||||
or pull request](https://github.com/Microsoft/vcpkg) on the vcpkg repository.
|
||||
|
||||
## Building from git
|
||||
|
||||
If you get your code off a git repository instead of a release tarball, see
|
||||
the `GIT-INFO` file in the root directory for specific instructions on how to
|
||||
proceed.
|
||||
|
||||
# Unix
|
||||
|
||||
A normal Unix installation is made in three or four steps (after you have
|
||||
unpacked the source archive):
|
||||
|
||||
./configure --with-openssl [--with-gnutls --with-wolfssl]
|
||||
make
|
||||
make test (optional)
|
||||
make install
|
||||
|
||||
(Adjust the configure line accordingly to use the TLS library you want.)
|
||||
|
||||
You probably need to be root when doing the last command.
|
||||
|
||||
Get a full listing of all available configure options by invoking it like:
|
||||
|
||||
./configure --help
|
||||
|
||||
If you want to install curl in a different file hierarchy than `/usr/local`,
|
||||
specify that when running configure:
|
||||
|
||||
./configure --prefix=/path/to/curl/tree
|
||||
|
||||
If you have write permission in that directory, you can do 'make install'
|
||||
without being root. An example of this would be to make a local install in
|
||||
your own home directory:
|
||||
|
||||
./configure --prefix=$HOME
|
||||
make
|
||||
make install
|
||||
|
||||
The configure script always tries to find a working SSL library unless
|
||||
explicitly told not to. If you have OpenSSL installed in the default search
|
||||
path for your compiler/linker, you do not need to do anything special. If you
|
||||
have OpenSSL installed in `/usr/local/ssl`, you can run configure like:
|
||||
|
||||
./configure --with-openssl
|
||||
|
||||
If you have OpenSSL installed somewhere else (for example, `/opt/OpenSSL`) and
|
||||
you have pkg-config installed, set the pkg-config path first, like this:
|
||||
|
||||
env PKG_CONFIG_PATH=/opt/OpenSSL/lib/pkgconfig ./configure --with-openssl
|
||||
|
||||
Without pkg-config installed, use this:
|
||||
|
||||
./configure --with-openssl=/opt/OpenSSL
|
||||
|
||||
If you insist on forcing a build without SSL support, you can run configure
|
||||
like this:
|
||||
|
||||
./configure --without-ssl
|
||||
|
||||
If you have OpenSSL installed, but with the libraries in one place and the
|
||||
header files somewhere else, you have to set the `LDFLAGS` and `CPPFLAGS`
|
||||
environment variables prior to running configure. Something like this should
|
||||
work:
|
||||
|
||||
CPPFLAGS="-I/path/to/ssl/include" LDFLAGS="-L/path/to/ssl/lib" ./configure
|
||||
|
||||
If you have shared SSL libs installed in a directory where your runtime
|
||||
linker does not find them (which usually causes configure failures), you can
|
||||
provide this option to gcc to set a hard-coded path to the runtime linker:
|
||||
|
||||
LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-openssl
|
||||
|
||||
## Static builds
|
||||
|
||||
To force a static library compile, disable the shared library creation by
|
||||
running configure like:
|
||||
|
||||
./configure --disable-shared
|
||||
|
||||
The configure script is primarily done to work with shared/dynamic third party
|
||||
dependencies. When linking with shared libraries, the dependency "chain" is
|
||||
handled automatically by the library loader - on all modern systems.
|
||||
|
||||
If you instead link with a static library, you need to provide all the
|
||||
dependency libraries already at the link command line.
|
||||
|
||||
Figuring out all the dependency libraries for a given library is hard, as it
|
||||
might involve figuring out the dependencies of the dependencies and they vary
|
||||
between platforms and change between versions.
|
||||
|
||||
When using static dependencies, the build scripts will mostly assume that you,
|
||||
the user, will provide all the necessary additional dependency libraries as
|
||||
additional arguments in the build. With configure, by setting `LIBS` or
|
||||
`LDFLAGS` on the command line.
|
||||
|
||||
Building statically is not for the faint of heart.
|
||||
|
||||
## Debug
|
||||
|
||||
If you are a curl developer and use gcc, you might want to enable more debug
|
||||
options with the `--enable-debug` option.
|
||||
|
||||
curl can be built to use a whole range of libraries to provide various useful
|
||||
services, and configure will try to auto-detect a decent default. But if you
|
||||
want to alter it, you can select how to deal with each individual library.
|
||||
|
||||
## Select TLS backend
|
||||
|
||||
These options are provided to select the TLS backend to use.
|
||||
|
||||
- AmiSSL: `--with-amissl`
|
||||
- BearSSL: `--with-bearssl`
|
||||
- GnuTLS: `--with-gnutls`.
|
||||
- mbedTLS: `--with-mbedtls`
|
||||
- NSS: `--with-nss`
|
||||
- OpenSSL: `--with-openssl` (also for BoringSSL, libressl and quictls)
|
||||
- rustls: `--with-rustls`
|
||||
- Schannel: `--with-schannel`
|
||||
- Secure Transport: `--with-secure-transport`
|
||||
- wolfSSL: `--with-wolfssl`
|
||||
|
||||
You can build curl with *multiple* TLS backends at your choice, but some TLS
|
||||
backends cannot be combined: if you build with an OpenSSL fork (or wolfSSL),
|
||||
you cannot add another OpenSSL fork (or wolfSSL) simply because they have
|
||||
conflicting identical symbol names.
|
||||
|
||||
When you build with multiple TLS backends, you can select the active one at
|
||||
run-time when curl starts up.
|
||||
|
||||
# Windows
|
||||
|
||||
## Building Windows DLLs and C runtime (CRT) linkage issues
|
||||
|
||||
As a general rule, building a DLL with static CRT linkage is highly
|
||||
discouraged, and intermixing CRTs in the same app is something to avoid at
|
||||
any cost.
|
||||
|
||||
Reading and comprehending Microsoft Knowledge Base articles KB94248 and
|
||||
KB140584 is a must for any Windows developer. Especially important is full
|
||||
understanding if you are not going to follow the advice given above.
|
||||
|
||||
- [How To Use the C Run-Time](https://support.microsoft.com/help/94248/how-to-use-the-c-run-time)
|
||||
- [Run-Time Library Compiler Options](https://docs.microsoft.com/cpp/build/reference/md-mt-ld-use-run-time-library)
|
||||
- [Potential Errors Passing CRT Objects Across DLL Boundaries](https://docs.microsoft.com/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries)
|
||||
|
||||
If your app is misbehaving in some strange way, or it is suffering from memory
|
||||
corruption, before asking for further help, please try first to rebuild every
|
||||
single library your app uses as well as your app using the debug
|
||||
multi-threaded dynamic C runtime.
|
||||
|
||||
If you get linkage errors read section 5.7 of the FAQ document.
|
||||
|
||||
## MinGW32
|
||||
|
||||
Make sure that MinGW32's bin directory is in the search path, for example:
|
||||
|
||||
```cmd
|
||||
set PATH=c:\mingw32\bin;%PATH%
|
||||
```
|
||||
|
||||
then run `mingw32-make mingw32` in the root dir. There are other
|
||||
make targets available to build libcurl with more features, use:
|
||||
|
||||
- `mingw32-make mingw32-zlib` to build with Zlib support;
|
||||
- `mingw32-make mingw32-ssl-zlib` to build with SSL and Zlib enabled;
|
||||
- `mingw32-make mingw32-ssh2-ssl-zlib` to build with SSH2, SSL, Zlib;
|
||||
- `mingw32-make mingw32-ssh2-ssl-sspi-zlib` to build with SSH2, SSL, Zlib
|
||||
and SSPI support.
|
||||
|
||||
If you have any problems linking libraries or finding header files, be sure
|
||||
to verify that the provided `Makefile.mk` files use the proper paths, and
|
||||
adjust as necessary. It is also possible to override these paths with
|
||||
environment variables, for example:
|
||||
|
||||
```cmd
|
||||
set ZLIB_PATH=c:\zlib-1.2.12
|
||||
set OPENSSL_PATH=c:\openssl-3.0.5
|
||||
set LIBSSH2_PATH=c:\libssh2-1.10.0
|
||||
```
|
||||
|
||||
It is also possible to build with other LDAP installations than MS LDAP;
|
||||
currently it is possible to build with native Win32 OpenLDAP, or with the
|
||||
*Novell CLDAP* SDK. If you want to use these you need to set these vars:
|
||||
|
||||
```cmd
|
||||
set CPPFLAGS=-Ic:/openldap/include -DCURL_HAS_OPENLDAP_LDAPSDK
|
||||
set LDFLAGS=-Lc:/openldap/lib
|
||||
set LIBS=-lldap -llber
|
||||
```
|
||||
|
||||
or for using the Novell SDK:
|
||||
|
||||
```cmd
|
||||
set CPPFLAGS=-Ic:/openldapsdk/inc -DCURL_HAS_NOVELL_LDAPSDK
|
||||
set LDFLAGS=-Lc:/openldapsdk/lib/mscvc
|
||||
set LIBS=-lldapsdk -lldapssl -lldapx
|
||||
```
|
||||
|
||||
If you want to enable LDAPS support then append `-ldaps` to the make target.
|
||||
|
||||
## Cygwin
|
||||
|
||||
Almost identical to the Unix installation. Run the configure script in the
|
||||
curl source tree root with `sh configure`. Make sure you have the `sh`
|
||||
executable in `/bin/` or you will see the configure fail toward the end.
|
||||
|
||||
Run `make`
|
||||
|
||||
## MS-DOS
|
||||
|
||||
Requires DJGPP in the search path and pointing to the Watt-32 stack via
|
||||
`WATT_PATH=c:/djgpp/net/watt`.
|
||||
|
||||
Run `make -f Makefile.dist djgpp` in the root curl dir.
|
||||
|
||||
For build configuration options, please see the MinGW32 section.
|
||||
|
||||
Notes:
|
||||
|
||||
- DJGPP 2.04 beta has a `sscanf()` bug so the URL parsing is not done
|
||||
properly. Use DJGPP 2.03 until they fix it.
|
||||
|
||||
- Compile Watt-32 (and OpenSSL) with the same version of DJGPP. Otherwise
|
||||
things go wrong because things like FS-extensions and `errno` values have
|
||||
been changed between releases.
|
||||
|
||||
## AmigaOS
|
||||
|
||||
Run `make -f Makefile.dist amiga` in the root curl dir.
|
||||
|
||||
For build configuration options, please see the MinGW32 section.
|
||||
|
||||
## Disabling Specific Protocols in Windows builds
|
||||
|
||||
The configure utility, unfortunately, is not available for the Windows
|
||||
environment, therefore, you cannot use the various disable-protocol options of
|
||||
the configure utility on this platform.
|
||||
|
||||
You can use specific defines to disable specific protocols and features. See
|
||||
[CURL-DISABLE](CURL-DISABLE.md) for the full list.
|
||||
|
||||
If you want to set any of these defines you have the following options:
|
||||
|
||||
- Modify `lib/config-win32.h`
|
||||
- Modify `lib/curl_setup.h`
|
||||
- Modify `winbuild/Makefile.vc`
|
||||
- Modify the "Preprocessor Definitions" in the libcurl project
|
||||
|
||||
Note: The pre-processor settings can be found using the Visual Studio IDE
|
||||
under "Project -> Properties -> Configuration Properties -> C/C++ ->
|
||||
Preprocessor".
|
||||
|
||||
## Using BSD-style lwIP instead of Winsock TCP/IP stack in Win32 builds
|
||||
|
||||
In order to compile libcurl and curl using BSD-style lwIP TCP/IP stack it is
|
||||
necessary to make the definition of the preprocessor symbol `USE_LWIPSOCK`
|
||||
visible to libcurl and curl compilation processes. To set this definition you
|
||||
have the following alternatives:
|
||||
|
||||
- Modify `lib/config-win32.h` and `src/config-win32.h`
|
||||
- Modify `winbuild/Makefile.vc`
|
||||
- Modify the "Preprocessor Definitions" in the libcurl project
|
||||
|
||||
Note: The pre-processor settings can be found using the Visual Studio IDE
|
||||
under "Project -> Properties -> Configuration Properties -> C/C++ ->
|
||||
Preprocessor".
|
||||
|
||||
Once that libcurl has been built with BSD-style lwIP TCP/IP stack support, in
|
||||
order to use it with your program it is mandatory that your program includes
|
||||
lwIP header file `<lwip/opt.h>` (or another lwIP header that includes this)
|
||||
before including any libcurl header. Your program does not need the
|
||||
`USE_LWIPSOCK` preprocessor definition which is for libcurl internals only.
|
||||
|
||||
Compilation has been verified with lwIP 1.4.0.
|
||||
|
||||
This BSD-style lwIP TCP/IP stack support must be considered experimental given
|
||||
that it has been verified that lwIP 1.4.0 still needs some polish, and libcurl
|
||||
might yet need some additional adjustment.
|
||||
|
||||
## Important static libcurl usage note
|
||||
|
||||
When building an application that uses the static libcurl library on Windows,
|
||||
you must add `-DCURL_STATICLIB` to your `CFLAGS`. Otherwise the linker will
|
||||
look for dynamic import symbols.
|
||||
|
||||
## Legacy Windows and SSL
|
||||
|
||||
Schannel (from Windows SSPI), is the native SSL library in Windows. However,
|
||||
Schannel in Windows <= XP is unable to connect to servers that
|
||||
no longer support the legacy handshakes and algorithms used by those
|
||||
versions. If you will be using curl in one of those earlier versions of
|
||||
Windows you should choose another SSL backend such as OpenSSL.
|
||||
|
||||
# Apple Platforms (macOS, iOS, tvOS, watchOS, and their simulator counterparts)
|
||||
|
||||
On modern Apple operating systems, curl can be built to use Apple's SSL/TLS
|
||||
implementation, Secure Transport, instead of OpenSSL. To build with Secure
|
||||
Transport for SSL/TLS, use the configure option `--with-secure-transport`.
|
||||
|
||||
When Secure Transport is in use, the curl options `--cacert` and `--capath`
|
||||
and their libcurl equivalents, will be ignored, because Secure Transport uses
|
||||
the certificates stored in the Keychain to evaluate whether or not to trust
|
||||
the server. This, of course, includes the root certificates that ship with the
|
||||
OS. The `--cert` and `--engine` options, and their libcurl equivalents, are
|
||||
currently unimplemented in curl with Secure Transport.
|
||||
|
||||
In general, a curl build for an Apple `ARCH/SDK/DEPLOYMENT_TARGET` combination
|
||||
can be taken by providing appropriate values for `ARCH`, `SDK`, `DEPLOYMENT_TARGET`
|
||||
below and running the commands:
|
||||
|
||||
```bash
|
||||
# Set these three according to your needs
|
||||
export ARCH=x86_64
|
||||
export SDK=macosx
|
||||
export DEPLOYMENT_TARGET=10.8
|
||||
|
||||
export CFLAGS="-arch $ARCH -isysroot $(xcrun -sdk $SDK --show-sdk-path) -m$SDK-version-min=$DEPLOYMENT_TARGET"
|
||||
./configure --host=$ARCH-apple-darwin --prefix $(pwd)/artifacts --with-secure-transport
|
||||
make -j8
|
||||
make install
|
||||
```
|
||||
|
||||
Above will build curl for macOS platform with `x86_64` architecture and `10.8` as deployment target.
|
||||
|
||||
Here is an example for iOS device:
|
||||
|
||||
```bash
|
||||
export ARCH=arm64
|
||||
export SDK=iphoneos
|
||||
export DEPLOYMENT_TARGET=11.0
|
||||
|
||||
export CFLAGS="-arch $ARCH -isysroot $(xcrun -sdk $SDK --show-sdk-path) -m$SDK-version-min=$DEPLOYMENT_TARGET"
|
||||
./configure --host=$ARCH-apple-darwin --prefix $(pwd)/artifacts --with-secure-transport
|
||||
make -j8
|
||||
make install
|
||||
```
|
||||
|
||||
Another example for watchOS simulator for macs with Apple Silicon:
|
||||
|
||||
```bash
|
||||
export ARCH=arm64
|
||||
export SDK=watchsimulator
|
||||
export DEPLOYMENT_TARGET=5.0
|
||||
|
||||
export CFLAGS="-arch $ARCH -isysroot $(xcrun -sdk $SDK --show-sdk-path) -m$SDK-version-min=$DEPLOYMENT_TARGET"
|
||||
./configure --host=$ARCH-apple-darwin --prefix $(pwd)/artifacts --with-secure-transport
|
||||
make -j8
|
||||
make install
|
||||
```
|
||||
|
||||
In all above, the built libraries and executables can be found in the
|
||||
`artifacts` folder.
|
||||
|
||||
# Android
|
||||
|
||||
When building curl for Android it's recommended to use a Linux/macOS environment
|
||||
since using curl's `configure` script is the easiest way to build curl
|
||||
for Android. Before you can build curl for Android, you need to install the
|
||||
Android NDK first. This can be done using the SDK Manager that is part of
|
||||
Android Studio. Once you have installed the Android NDK, you need to figure out
|
||||
where it has been installed and then set up some environment variables before
|
||||
launching `configure`. On macOS, those variables could look like this to compile
|
||||
for `aarch64` and API level 29:
|
||||
|
||||
```bash
|
||||
export ANDROID_NDK_HOME=~/Library/Android/sdk/ndk/25.1.8937393 # Point into your NDK.
|
||||
export HOST_TAG=darwin-x86_64 # Same tag for Apple Silicon. Other OS values here: https://developer.android.com/ndk/guides/other_build_systems#overview
|
||||
export TOOLCHAIN=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/$HOST_TAG
|
||||
export AR=$TOOLCHAIN/bin/llvm-ar
|
||||
export AS=$TOOLCHAIN/bin/llvm-as
|
||||
export CC=$TOOLCHAIN/bin/aarch64-linux-android21-clang
|
||||
export CXX=$TOOLCHAIN/bin/aarch64-linux-android21-clang++
|
||||
export LD=$TOOLCHAIN/bin/ld
|
||||
export RANLIB=$TOOLCHAIN/bin/llvm-ranlib
|
||||
export STRIP=$TOOLCHAIN/bin/llvm-strip
|
||||
```
|
||||
|
||||
When building on Linux or targeting other API levels or architectures, you need
|
||||
to adjust those variables accordingly. After that you can build curl like this:
|
||||
|
||||
./configure --host aarch64-linux-android --with-pic --disable-shared
|
||||
|
||||
Note that this will not give you SSL/TLS support. If you need SSL/TLS, you have
|
||||
to build curl against a SSL/TLS layer, e.g. OpenSSL, because it's impossible for
|
||||
curl to access Android's native SSL/TLS layer. To build curl for Android using
|
||||
OpenSSL, follow the OpenSSL build instructions and then install `libssl.a` and
|
||||
`libcrypto.a` to `$TOOLCHAIN/sysroot/usr/lib` and copy `include/openssl` to
|
||||
`$TOOLCHAIN/sysroot/usr/include`. Now you can build curl for Android using
|
||||
OpenSSL like this:
|
||||
|
||||
```bash
|
||||
LIBS="-lssl -lcrypto -lc++" # For OpenSSL/BoringSSL. In general, you'll need to the SSL/TLS layer's transtive dependencies if you're linking statically.
|
||||
./configure --host aarch64-linux-android --with-pic --disable-shared --with-openssl="$TOOLCHAIN/sysroot/usr"
|
||||
```
|
||||
|
||||
# IBM i
|
||||
|
||||
For IBM i (formerly OS/400), you can use curl in two different ways:
|
||||
|
||||
- Natively, running in the **ILE**. The obvious use is being able to call curl
|
||||
from ILE C or RPG applications.
|
||||
- You will need to build this from source. See `packages/OS400/README` for
|
||||
the ILE specific build instructions.
|
||||
- In the **PASE** environment, which runs AIX programs. curl will be built as
|
||||
it would be on AIX.
|
||||
- IBM provides builds of curl in their Yum repository for PASE software.
|
||||
- To build from source, follow the Unix instructions.
|
||||
|
||||
There are some additional limitations and quirks with curl on this platform;
|
||||
they affect both environments.
|
||||
|
||||
## Multi-threading notes
|
||||
|
||||
By default, jobs in IBM i will not start with threading enabled. (Exceptions
|
||||
include interactive PASE sessions started by `QP2TERM` or SSH.) If you use
|
||||
curl in an environment without threading when options like asynchronous DNS
|
||||
were enabled, you will get messages like:
|
||||
|
||||
```
|
||||
getaddrinfo() thread failed to start
|
||||
```
|
||||
|
||||
Do not panic. curl and your program are not broken. You can fix this by:
|
||||
|
||||
- Set the environment variable `QIBM_MULTI_THREADED` to `Y` before starting
|
||||
your program. This can be done at whatever scope you feel is appropriate.
|
||||
- Alternatively, start the job with the `ALWMLTTHD` parameter set to `*YES`.
|
||||
|
||||
# Cross compile
|
||||
|
||||
Download and unpack the curl package.
|
||||
|
||||
`cd` to the new directory. (e.g. `cd curl-7.12.3`)
|
||||
|
||||
Set environment variables to point to the cross-compile toolchain and call
|
||||
configure with any options you need. Be sure and specify the `--host` and
|
||||
`--build` parameters at configuration time. The following script is an example
|
||||
of cross-compiling for the IBM 405GP PowerPC processor using the toolchain on
|
||||
Linux.
|
||||
|
||||
```bash
|
||||
#! /bin/sh
|
||||
|
||||
export PATH=$PATH:/opt/hardhat/devkit/ppc/405/bin
|
||||
export CPPFLAGS="-I/opt/hardhat/devkit/ppc/405/target/usr/include"
|
||||
export AR=ppc_405-ar
|
||||
export AS=ppc_405-as
|
||||
export LD=ppc_405-ld
|
||||
export RANLIB=ppc_405-ranlib
|
||||
export CC=ppc_405-gcc
|
||||
export NM=ppc_405-nm
|
||||
|
||||
./configure --target=powerpc-hardhat-linux
|
||||
--host=powerpc-hardhat-linux
|
||||
--build=i586-pc-linux-gnu
|
||||
--prefix=/opt/hardhat/devkit/ppc/405/target/usr/local
|
||||
--exec-prefix=/usr/local
|
||||
```
|
||||
|
||||
You may also need to provide a parameter like `--with-random=/dev/urandom` to
|
||||
configure as it cannot detect the presence of a random number generating
|
||||
device for a target system. The `--prefix` parameter specifies where curl
|
||||
will be installed. If `configure` completes successfully, do `make` and `make
|
||||
install` as usual.
|
||||
|
||||
In some cases, you may be able to simplify the above commands to as little as:
|
||||
|
||||
./configure --host=ARCH-OS
|
||||
|
||||
# REDUCING SIZE
|
||||
|
||||
There are a number of configure options that can be used to reduce the size of
|
||||
libcurl for embedded applications where binary size is an important factor.
|
||||
First, be sure to set the `CFLAGS` variable when configuring with any relevant
|
||||
compiler optimization flags to reduce the size of the binary. For gcc, this
|
||||
would mean at minimum the -Os option, and potentially the `-march=X`,
|
||||
`-mdynamic-no-pic` and `-flto` options as well, e.g.
|
||||
|
||||
./configure CFLAGS='-Os' LDFLAGS='-Wl,-Bsymbolic'...
|
||||
|
||||
Note that newer compilers often produce smaller code than older versions
|
||||
due to improved optimization.
|
||||
|
||||
Be sure to specify as many `--disable-` and `--without-` flags on the
|
||||
configure command-line as you can to disable all the libcurl features that you
|
||||
know your application is not going to need. Besides specifying the
|
||||
`--disable-PROTOCOL` flags for all the types of URLs your application will not
|
||||
use, here are some other flags that can reduce the size of the library by
|
||||
disabling support for some feature:
|
||||
|
||||
- `--disable-alt-svc` (HTTP Alt-Svc)
|
||||
- `--disable-ares` (the C-ARES DNS library)
|
||||
- `--disable-cookies` (HTTP cookies)
|
||||
- `--disable-crypto-auth` (cryptographic authentication)
|
||||
- `--disable-dateparse` (date parsing for time conditionals)
|
||||
- `--disable-dnsshuffle` (internal server load spreading)
|
||||
- `--disable-doh` (DNS-over-HTTP)
|
||||
- `--disable-get-easy-options` (lookup easy options at runtime)
|
||||
- `--disable-hsts` (HTTP Strict Transport Security)
|
||||
- `--disable-http-auth` (all HTTP authentication)
|
||||
- `--disable-ipv6` (IPv6)
|
||||
- `--disable-libcurl-option` (--libcurl C code generation support)
|
||||
- `--disable-manual` (built-in documentation)
|
||||
- `--disable-netrc` (.netrc file)
|
||||
- `--disable-ntlm-wb` (NTLM WinBind)
|
||||
- `--disable-progress-meter` (graphical progress meter in library)
|
||||
- `--disable-proxy` (HTTP and SOCKS proxies)
|
||||
- `--disable-pthreads` (multi-threading)
|
||||
- `--disable-socketpair` (socketpair for asynchronous name resolving)
|
||||
- `--disable-threaded-resolver` (threaded name resolver)
|
||||
- `--disable-tls-srp` (Secure Remote Password authentication for TLS)
|
||||
- `--disable-unix-sockets` (UNIX sockets)
|
||||
- `--disable-verbose` (eliminates debugging strings and error code strings)
|
||||
- `--disable-versioned-symbols` (versioned symbols)
|
||||
- `--enable-symbol-hiding` (eliminates unneeded symbols in the shared library)
|
||||
- `--without-brotli` (Brotli on-the-fly decompression)
|
||||
- `--without-libpsl` (Public Suffix List in cookies)
|
||||
- `--without-nghttp2` (HTTP/2 using nghttp2)
|
||||
- `--without-ngtcp2` (HTTP/2 using ngtcp2)
|
||||
- `--without-zstd` (Zstd on-the-fly decompression)
|
||||
- `--without-libidn2` (internationalized domain names)
|
||||
- `--without-librtmp` (RTMP)
|
||||
- `--without-ssl` (SSL/TLS)
|
||||
- `--without-zlib` (on-the-fly decompression)
|
||||
|
||||
The GNU compiler and linker have a number of options that can reduce the
|
||||
size of the libcurl dynamic libraries on some platforms even further.
|
||||
Specify them by providing appropriate `CFLAGS` and `LDFLAGS` variables on
|
||||
the configure command-line, e.g.
|
||||
|
||||
CFLAGS="-Os -ffunction-sections -fdata-sections
|
||||
-fno-unwind-tables -fno-asynchronous-unwind-tables -flto"
|
||||
LDFLAGS="-Wl,-s -Wl,-Bsymbolic -Wl,--gc-sections"
|
||||
|
||||
Be sure also to strip debugging symbols from your binaries after compiling
|
||||
using 'strip' (or the appropriate variant if cross-compiling). If space is
|
||||
really tight, you may be able to remove some unneeded sections of the shared
|
||||
library using the -R option to objcopy (e.g. the .comment section).
|
||||
|
||||
Using these techniques it is possible to create a basic HTTP-only libcurl
|
||||
shared library for i386 Linux platforms that is only 133 KiB in size
|
||||
(as of libcurl version 7.80.0, using gcc 11.2.0).
|
||||
|
||||
You may find that statically linking libcurl to your application will result
|
||||
in a lower total size than dynamically linking.
|
||||
|
||||
Note that the curl test harness can detect the use of some, but not all, of
|
||||
the `--disable` statements suggested above. Use will cause tests relying on
|
||||
those features to fail. The test harness can be manually forced to skip the
|
||||
relevant tests by specifying certain key words on the `runtests.pl` command
|
||||
line. Following is a list of appropriate key words for those configure options
|
||||
that are not automatically detected:
|
||||
|
||||
- `--disable-cookies` !cookies
|
||||
- `--disable-dateparse` !RETRY-AFTER !`CURLOPT_TIMECONDITION` !`CURLINFO_FILETIME` !`If-Modified-Since` !`curl_getdate` !`-z`
|
||||
- `--disable-libcurl-option` !`--libcurl`
|
||||
- `--disable-verbose` !verbose\ logs
|
||||
|
||||
# PORTS
|
||||
|
||||
This is a probably incomplete list of known CPU architectures and operating
|
||||
systems that curl has been compiled for. If you know a system curl compiles
|
||||
and runs on, that is not listed, please let us know!
|
||||
|
||||
## 92 Operating Systems
|
||||
|
||||
AIX, AmigaOS, Android, Aros, BeOS, Blackberry 10, Blackberry Tablet OS,
|
||||
Cell OS, Chrome OS, Cisco IOS, Cygwin, DG/UX, Dragonfly BSD, DR DOS, eCOS,
|
||||
FreeBSD, FreeDOS, FreeRTOS, Fuchsia, Garmin OS, Genode, Haiku, HardenedBSD,
|
||||
HP-UX, Hurd, Illumos, Integrity, iOS, ipadOS, IRIX, Linux, Lua RTOS,
|
||||
Mac OS 9, macOS, Mbed, Micrium, MINIX, MorphOS, MPE/iX, MS-DOS, NCR MP-RAS,
|
||||
NetBSD, Netware, Nintendo Switch, NonStop OS, NuttX, Omni OS, OpenBSD,
|
||||
OpenStep, Orbis OS, OS/2, OS/400, OS21, Plan 9, PlayStation Portable, QNX,
|
||||
Qubes OS, ReactOS, Redox, RICS OS, RTEMS, Sailfish OS, SCO Unix, Serenity,
|
||||
SINIX-Z, Solaris, SunOS, Syllable OS, Symbian, Tizen, TPF, Tru64, tvOS,
|
||||
ucLinux, Ultrix, UNICOS, UnixWare, VMS, vxWorks, watchOS, WebOS,
|
||||
Wii system software, Windows, Windows CE, Xbox System, Xenix, Zephyr,
|
||||
z/OS, z/TPF, z/VM, z/VSE
|
||||
|
||||
## 26 CPU Architectures
|
||||
|
||||
Alpha, ARC, ARM, AVR32, CompactRISC, Elbrus, ETRAX, HP-PA, Itanium,
|
||||
LoongArch, m68k, m88k, MicroBlaze, MIPS, Nios, OpenRISC, POWER, PowerPC,
|
||||
RISC-V, s390, SH4, SPARC, Tilera, VAX, x86, Xtensa
|
||||
@ -0,0 +1,9 @@
|
||||
_ _ ____ _
|
||||
___| | | | _ \| |
|
||||
/ __| | | | |_) | |
|
||||
| (__| |_| | _ <| |___
|
||||
\___|\___/|_| \_\_____|
|
||||
|
||||
How To Compile
|
||||
|
||||
see INSTALL.md
|
||||
@ -0,0 +1,58 @@
|
||||
# curl internals
|
||||
|
||||
The canonical libcurl internals documentation is now in the [everything
|
||||
curl](https://everything.curl.dev/internals) book. This file lists supported
|
||||
versions of libs and build tools.
|
||||
|
||||
## Portability
|
||||
|
||||
We write curl and libcurl to compile with C89 compilers on 32-bit and up
|
||||
machines. Most of libcurl assumes more or less POSIX compliance but that is
|
||||
not a requirement.
|
||||
|
||||
We write libcurl to build and work with lots of third party tools, and we
|
||||
want it to remain functional and buildable with these and later versions
|
||||
(older versions may still work but is not what we work hard to maintain):
|
||||
|
||||
## Dependencies
|
||||
|
||||
We aim to support these or later versions.
|
||||
|
||||
- OpenSSL 0.9.7
|
||||
- GnuTLS 3.1.10
|
||||
- zlib 1.1.4
|
||||
- libssh2 1.0
|
||||
- c-ares 1.16.0
|
||||
- libidn2 2.0.0
|
||||
- wolfSSL 2.0.0
|
||||
- OpenLDAP 2.0
|
||||
- MIT Kerberos 1.2.4
|
||||
- GSKit V5R3M0
|
||||
- NSS 3.14.x
|
||||
- Heimdal ?
|
||||
- nghttp2 1.12.0
|
||||
- WinSock 2.2 (on Windows 95+ and Windows CE .NET 4.1+)
|
||||
|
||||
## Build tools
|
||||
|
||||
When writing code (mostly for generating stuff included in release tarballs)
|
||||
we use a few "build tools" and we make sure that we remain functional with
|
||||
these versions:
|
||||
|
||||
- GNU Libtool 1.4.2
|
||||
- GNU Autoconf 2.59
|
||||
- GNU Automake 1.7
|
||||
- GNU M4 1.4
|
||||
- perl 5.004
|
||||
- roffit 0.5
|
||||
- nroff any version that supports `-man [in] [out]`
|
||||
- cmake 3.7
|
||||
|
||||
Library Symbols
|
||||
===============
|
||||
|
||||
All symbols used internally in libcurl must use a `Curl_` prefix if they are
|
||||
used in more than a single file. Single-file symbols must be made static.
|
||||
Public ("exported") symbols must use a `curl_` prefix. Public API functions
|
||||
are marked with `CURL_EXTERN` in the public header files so that all others
|
||||
can be hidden on platforms where this is possible.
|
||||
@ -0,0 +1,749 @@
|
||||
_ _ ____ _
|
||||
___| | | | _ \| |
|
||||
/ __| | | | |_) | |
|
||||
| (__| |_| | _ <| |___
|
||||
\___|\___/|_| \_\_____|
|
||||
|
||||
Known Bugs
|
||||
|
||||
These are problems and bugs known to exist at the time of this release. Feel
|
||||
free to join in and help us correct one or more of these. Also be sure to
|
||||
check the changelog of the current development status, as one or more of these
|
||||
problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
1. HTTP
|
||||
1.5 Expect-100 meets 417
|
||||
|
||||
2. TLS
|
||||
2.3 Unable to use PKCS12 certificate with Secure Transport
|
||||
2.4 Secure Transport will not import PKCS#12 client certificates without a password
|
||||
2.5 Client cert handling with Issuer DN differs between backends
|
||||
2.7 Client cert (MTLS) issues with Schannel
|
||||
2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
|
||||
2.9 TLS session cache does not work with TFO
|
||||
2.11 Schannel TLS 1.2 handshake bug in old Windows versions
|
||||
2.12 FTPS with Schannel times out file list operation
|
||||
2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
|
||||
2.15 Renegotiate from server may cause hang for OpenSSL backend
|
||||
|
||||
3. Email protocols
|
||||
3.1 IMAP SEARCH ALL truncated response
|
||||
3.2 No disconnect command
|
||||
3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
|
||||
3.4 AUTH PLAIN for SMTP is not working on all servers
|
||||
|
||||
4. Command line
|
||||
4.1 -J and -O with %-encoded file names
|
||||
4.2 -J with -C - fails
|
||||
4.3 --retry and transfer timeouts
|
||||
|
||||
5. Build and portability issues
|
||||
5.1 OS400 port requires deprecated IBM library
|
||||
5.2 curl-config --libs contains private details
|
||||
5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
|
||||
5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
|
||||
5.6 make distclean loops forever
|
||||
5.8 configure finding libs in wrong directory
|
||||
5.9 Utilize Requires.private directives in libcurl.pc
|
||||
5.11 configure --with-gssapi with Heimdal is ignored on macOS
|
||||
5.12 flaky Windows CI builds
|
||||
5.13 long paths are not fully supported on Windows
|
||||
5.14 Windows Unicode builds use homedir in current locale
|
||||
|
||||
6. Authentication
|
||||
6.1 NTLM authentication and unicode
|
||||
6.2 MIT Kerberos for Windows build
|
||||
6.3 NTLM in system context uses wrong name
|
||||
6.4 Negotiate and Kerberos V5 need a fake user name
|
||||
6.5 NTLM does not support password with § character
|
||||
6.6 libcurl can fail to try alternatives with --proxy-any
|
||||
6.7 Do not clear digest for single realm
|
||||
6.9 SHA-256 digest not supported in Windows SSPI builds
|
||||
6.10 curl never completes Negotiate over HTTP
|
||||
6.11 Negotiate on Windows fails
|
||||
6.12 cannot use Secure Transport with Crypto Token Kit
|
||||
6.13 Negotiate against Hadoop HDFS
|
||||
|
||||
7. FTP
|
||||
7.3 FTP with NOBODY and FAILONERROR
|
||||
7.4 FTP with ACCT
|
||||
7.11 FTPS upload data loss with TLS 1.3
|
||||
7.12 FTPS directory listing hangs on Windows with Schannel
|
||||
|
||||
9. SFTP and SCP
|
||||
9.1 SFTP does not do CURLOPT_POSTQUOTE correct
|
||||
9.2 wolfssh: publickey auth does not work
|
||||
9.3 Remote recursive folder creation with SFTP
|
||||
9.4 libssh blocking and infinite loop problem
|
||||
|
||||
10. SOCKS
|
||||
10.3 FTPS over SOCKS
|
||||
|
||||
11. Internals
|
||||
11.1 Curl leaks .onion hostnames in DNS
|
||||
11.2 error buffer not set if connection to multiple addresses fails
|
||||
11.4 HTTP test server 'connection-monitor' problems
|
||||
11.5 Connection information when using TCP Fast Open
|
||||
11.7 signal-based resolver timeouts
|
||||
11.10 Blocking socket operations in non-blocking API
|
||||
11.11 A shared connection cache is not thread-safe
|
||||
11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing
|
||||
11.16 libcurl uses renames instead of locking for atomic operations
|
||||
|
||||
12. LDAP
|
||||
12.1 OpenLDAP hangs after returning results
|
||||
12.2 LDAP on Windows does authentication wrong?
|
||||
12.3 LDAP on Windows does not work
|
||||
12.4 LDAPS with NSS is slow
|
||||
|
||||
13. TCP/IP
|
||||
13.2 Trying local ports fails on Windows
|
||||
|
||||
15. CMake
|
||||
15.2 support build with GnuTLS
|
||||
15.3 unusable tool_hugehelp.c with MinGW
|
||||
15.4 build docs/curl.1
|
||||
15.5 build on Linux links libcurl to libdl
|
||||
15.6 uses -lpthread instead of Threads::Threads
|
||||
15.7 generated .pc file contains strange entries
|
||||
15.8 libcurl.pc uses absolute library paths
|
||||
15.10 libpsl is not supported
|
||||
15.11 ExternalProject_Add does not set CURL_CA_PATH
|
||||
15.13 CMake build with MIT Kerberos does not work
|
||||
|
||||
16. Applications
|
||||
|
||||
17. HTTP/2
|
||||
17.2 HTTP/2 frames while in the connection pool kill reuse
|
||||
17.3 ENHANCE_YOUR_CALM causes infinite retries
|
||||
|
||||
18. HTTP/3
|
||||
18.1 If the HTTP/3 server closes connection during upload curl hangs
|
||||
18.2 Transfer closed with n bytes remaining to read
|
||||
18.4 timeout when reusing an http3 connection
|
||||
18.9 connection migration does not work
|
||||
|
||||
==============================================================================
|
||||
|
||||
1. HTTP
|
||||
|
||||
1.5 Expect-100 meets 417
|
||||
|
||||
If an upload using Expect: 100-continue receives an HTTP 417 response, it
|
||||
ought to be automatically resent without the Expect:. A workaround is for
|
||||
the client application to redo the transfer after disabling Expect:.
|
||||
https://curl.se/mail/archive-2008-02/0043.html
|
||||
|
||||
2. TLS
|
||||
|
||||
2.3 Unable to use PKCS12 certificate with Secure Transport
|
||||
|
||||
See https://github.com/curl/curl/issues/5403
|
||||
|
||||
2.4 Secure Transport will not import PKCS#12 client certificates without a password
|
||||
|
||||
libcurl calls SecPKCS12Import with the PKCS#12 client certificate, but that
|
||||
function rejects certificates that do not have a password.
|
||||
https://github.com/curl/curl/issues/1308
|
||||
|
||||
2.5 Client cert handling with Issuer DN differs between backends
|
||||
|
||||
When the specified client certificate does not match any of the
|
||||
server-specified DNs, the OpenSSL and GnuTLS backends behave differently.
|
||||
The github discussion may contain a solution.
|
||||
|
||||
See https://github.com/curl/curl/issues/1411
|
||||
|
||||
2.7 Client cert (MTLS) issues with Schannel
|
||||
|
||||
See https://github.com/curl/curl/issues/3145
|
||||
|
||||
2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
|
||||
|
||||
This seems to be a limitation in the underlying Schannel API.
|
||||
|
||||
https://github.com/curl/curl/issues/3284
|
||||
|
||||
2.9 TLS session cache does not work with TFO
|
||||
|
||||
See https://github.com/curl/curl/issues/4301
|
||||
|
||||
2.11 Schannel TLS 1.2 handshake bug in old Windows versions
|
||||
|
||||
In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
|
||||
implementation likely has a bug that can rarely cause the key exchange to
|
||||
fail, resulting in error SEC_E_BUFFER_TOO_SMALL or SEC_E_MESSAGE_ALTERED.
|
||||
|
||||
https://github.com/curl/curl/issues/5488
|
||||
|
||||
2.12 FTPS with Schannel times out file list operation
|
||||
|
||||
"Instead of the command completing, it just sits there until the timeout
|
||||
expires." - the same command line seems to work with other TLS backends and
|
||||
other operating systems. See https://github.com/curl/curl/issues/5284.
|
||||
|
||||
2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
|
||||
|
||||
https://github.com/curl/curl/issues/8741
|
||||
|
||||
2.15 Renegotiate from server may cause hang for OpenSSL backend
|
||||
|
||||
A race condition has been observed when, immediately after the initial
|
||||
handshake, curl has sent an HTTP request to the server and at the same time
|
||||
the server has sent a TLS hello request (renegotiate) to curl. Both are
|
||||
waiting for the other to respond. OpenSSL is supposed to send a handshake
|
||||
response but does not.
|
||||
|
||||
https://github.com/curl/curl/issues/6785
|
||||
https://github.com/openssl/openssl/issues/14722
|
||||
|
||||
3. Email protocols
|
||||
|
||||
3.1 IMAP SEARCH ALL truncated response
|
||||
|
||||
IMAP "SEARCH ALL" truncates output on large boxes. "A quick search of the
|
||||
code reveals that pingpong.c contains some truncation code, at line 408, when
|
||||
it deems the server response to be too large truncating it to 40 characters"
|
||||
https://curl.se/bug/view.cgi?id=1366
|
||||
|
||||
3.2 No disconnect command
|
||||
|
||||
The disconnect commands (LOGOUT and QUIT) may not be sent by IMAP, POP3 and
|
||||
SMTP if a failure occurs during the authentication phase of a connection.
|
||||
|
||||
3.3 POP3 expects "CRLF.CRLF" eob for some single-line responses
|
||||
|
||||
You have to tell libcurl not to expect a body, when dealing with one line
|
||||
response commands. Please see the POP3 examples and test cases which show
|
||||
this for the NOOP and DELE commands. https://curl.se/bug/?i=740
|
||||
|
||||
3.4 AUTH PLAIN for SMTP is not working on all servers
|
||||
|
||||
Specifying "--login-options AUTH=PLAIN" on the command line does not seem to
|
||||
work correctly.
|
||||
|
||||
See https://github.com/curl/curl/issues/4080
|
||||
|
||||
4. Command line
|
||||
|
||||
4.1 -J and -O with %-encoded file names
|
||||
|
||||
-J/--remote-header-name does not decode %-encoded file names. RFC6266 details
|
||||
how it should be done. The can of worm is basically that we have no charset
|
||||
handling in curl and ascii >=128 is a challenge for us. Not to mention that
|
||||
decoding also means that we need to check for nastiness that is attempted,
|
||||
like "../" sequences and the like. Probably everything to the left of any
|
||||
embedded slashes should be cut off.
|
||||
https://curl.se/bug/view.cgi?id=1294
|
||||
|
||||
-O also does not decode %-encoded names, and while it has even less
|
||||
information about the charset involved the process is similar to the -J case.
|
||||
|
||||
Note that we will not add decoding to -O without the user asking for it with
|
||||
some other means as well, since -O has always been documented to use the name
|
||||
exactly as specified in the URL.
|
||||
|
||||
4.2 -J with -C - fails
|
||||
|
||||
When using -J (with -O), automatically resumed downloading together with "-C
|
||||
-" fails. Without -J the same command line works. This happens because the
|
||||
resume logic is worked out before the target file name (and thus its
|
||||
pre-transfer size) has been figured out.
|
||||
https://curl.se/bug/view.cgi?id=1169
|
||||
|
||||
4.3 --retry and transfer timeouts
|
||||
|
||||
If using --retry and the transfer timeouts (possibly due to using -m or
|
||||
-y/-Y) the next attempt does not resume the transfer properly from what was
|
||||
downloaded in the previous attempt but will truncate and restart at the
|
||||
original position where it was at before the previous failed attempt. See
|
||||
https://curl.se/mail/lib-2008-01/0080.html and Mandriva bug report
|
||||
https://qa.mandriva.com/show_bug.cgi?id=22565
|
||||
|
||||
5. Build and portability issues
|
||||
|
||||
5.1 OS400 port requires deprecated IBM library
|
||||
|
||||
curl for OS400 requires QADRT to build, which provides ASCII wrappers for
|
||||
libc/POSIX functions in the ILE, but IBM no longer supports or even offers
|
||||
this library to download.
|
||||
|
||||
See https://github.com/curl/curl/issues/5176
|
||||
|
||||
5.2 curl-config --libs contains private details
|
||||
|
||||
"curl-config --libs" will include details set in LDFLAGS when configure is
|
||||
run that might be needed only for building libcurl. Further, curl-config
|
||||
--cflags suffers from the same effects with CFLAGS/CPPFLAGS.
|
||||
|
||||
5.3 curl compiled on OSX 10.13 failed to run on OSX 10.10
|
||||
|
||||
See https://github.com/curl/curl/issues/2905
|
||||
|
||||
5.5 cannot handle Unicode arguments in non-Unicode builds on Windows
|
||||
|
||||
If a URL or filename cannot be encoded using the user's current codepage then
|
||||
it can only be encoded properly in the Unicode character set. Windows uses
|
||||
UTF-16 encoding for Unicode and stores it in wide characters, however curl
|
||||
and libcurl are not equipped for that at the moment except when built with
|
||||
_UNICODE and UNICODE defined. And, except for Cygwin, Windows cannot use UTF-8
|
||||
as a locale.
|
||||
|
||||
https://curl.se/bug/?i=345
|
||||
https://curl.se/bug/?i=731
|
||||
https://curl.se/bug/?i=3747
|
||||
|
||||
5.6 make distclean loops forever
|
||||
|
||||
Due to an issue (probably) in automake, "make distclean" can end up in a
|
||||
never-ending loop.
|
||||
|
||||
See https://github.com/curl/curl/issues/7716
|
||||
|
||||
5.8 configure finding libs in wrong directory
|
||||
|
||||
When the configure script checks for third-party libraries, it adds those
|
||||
directories to the LDFLAGS variable and then tries linking to see if it
|
||||
works. When successful, the found directory is kept in the LDFLAGS variable
|
||||
when the script continues to execute and do more tests and possibly check for
|
||||
more libraries.
|
||||
|
||||
This can make subsequent checks for libraries wrongly detect another
|
||||
installation in a directory that was previously added to LDFLAGS by another
|
||||
library check.
|
||||
|
||||
A possibly better way to do these checks would be to keep the pristine LDFLAGS
|
||||
even after successful checks and instead add those verified paths to a
|
||||
separate variable that only after all library checks have been performed gets
|
||||
appended to LDFLAGS.
|
||||
|
||||
5.9 Utilize Requires.private directives in libcurl.pc
|
||||
|
||||
https://github.com/curl/curl/issues/864
|
||||
|
||||
5.11 configure --with-gssapi with Heimdal is ignored on macOS
|
||||
|
||||
... unless you also pass --with-gssapi-libs
|
||||
|
||||
https://github.com/curl/curl/issues/3841
|
||||
|
||||
5.12 flaky Windows CI builds
|
||||
|
||||
We run many CI builds for each commit and PR on github, and especially a
|
||||
number of the Windows builds are flaky. This means that we rarely get all CI
|
||||
builds go green and complete without errors. This is unfortunate as it makes
|
||||
us sometimes miss actual build problems and it is surprising to newcomers to
|
||||
the project who (rightfully) do not expect this.
|
||||
|
||||
See https://github.com/curl/curl/issues/6972
|
||||
|
||||
5.13 long paths are not fully supported on Windows
|
||||
|
||||
curl on Windows cannot access long paths (paths longer than 260 characters).
|
||||
However, as a workaround, the Windows path prefix \\?\ which disables all path
|
||||
interpretation may work to allow curl to access the path. For example:
|
||||
\\?\c:\longpath.
|
||||
|
||||
See https://github.com/curl/curl/issues/8361
|
||||
|
||||
5.14 Windows Unicode builds use homedir in current locale
|
||||
|
||||
The Windows Unicode builds of curl use the current locale, but expect Unicode
|
||||
UTF-8 encoded paths for internal use such as open, access and stat. The user's
|
||||
home directory is retrieved via curl_getenv in the current locale and not as
|
||||
UTF-8 encoded Unicode.
|
||||
|
||||
See https://github.com/curl/curl/pull/7252 and
|
||||
https://github.com/curl/curl/pull/7281
|
||||
|
||||
6. Authentication
|
||||
|
||||
6.1 NTLM authentication and unicode
|
||||
|
||||
NTLM authentication involving unicode user name or password only works
|
||||
properly if built with UNICODE defined together with the Schannel
|
||||
backend. The original problem was mentioned in:
|
||||
https://curl.se/mail/lib-2009-10/0024.html
|
||||
https://curl.se/bug/view.cgi?id=896
|
||||
|
||||
The Schannel version verified to work as mentioned in
|
||||
https://curl.se/mail/lib-2012-07/0073.html
|
||||
|
||||
6.2 MIT Kerberos for Windows build
|
||||
|
||||
libcurl fails to build with MIT Kerberos for Windows (KfW) due to KfW's
|
||||
library header files exporting symbols/macros that should be kept private to
|
||||
the KfW library. See ticket #5601 at https://krbdev.mit.edu/rt/
|
||||
|
||||
6.3 NTLM in system context uses wrong name
|
||||
|
||||
NTLM authentication using SSPI (on Windows) when (lib)curl is running in
|
||||
"system context" will make it use wrong(?) user name - at least when compared
|
||||
to what winhttp does. See https://curl.se/bug/view.cgi?id=535
|
||||
|
||||
6.4 Negotiate and Kerberos V5 need a fake user name
|
||||
|
||||
In order to get Negotiate (SPNEGO) authentication to work in HTTP or Kerberos
|
||||
V5 in the email protocols, you need to provide a (fake) user name (this
|
||||
concerns both curl and the lib) because the code wrongly only considers
|
||||
authentication if there's a user name provided by setting
|
||||
conn->bits.user_passwd in url.c https://curl.se/bug/view.cgi?id=440 How?
|
||||
https://curl.se/mail/lib-2004-08/0182.html A possible solution is to
|
||||
either modify this variable to be set or introduce a variable such as
|
||||
new conn->bits.want_authentication which is set when any of the authentication
|
||||
options are set.
|
||||
|
||||
6.5 NTLM does not support password with § character
|
||||
|
||||
https://github.com/curl/curl/issues/2120
|
||||
|
||||
6.6 libcurl can fail to try alternatives with --proxy-any
|
||||
|
||||
When connecting via a proxy using --proxy-any, a failure to establish an
|
||||
authentication will cause libcurl to abort trying other options if the
|
||||
failed method has a higher preference than the alternatives. As an example,
|
||||
--proxy-any against a proxy which advertise Negotiate and NTLM, but which
|
||||
fails to set up Kerberos authentication will not proceed to try authentication
|
||||
using NTLM.
|
||||
|
||||
https://github.com/curl/curl/issues/876
|
||||
|
||||
6.7 Do not clear digest for single realm
|
||||
|
||||
https://github.com/curl/curl/issues/3267
|
||||
|
||||
6.9 SHA-256 digest not supported in Windows SSPI builds
|
||||
|
||||
Windows builds of curl that have SSPI enabled use the native Windows API calls
|
||||
to create authentication strings. The call to InitializeSecurityContext fails
|
||||
with SEC_E_QOP_NOT_SUPPORTED which causes curl to fail with CURLE_AUTH_ERROR.
|
||||
|
||||
Microsoft does not document supported digest algorithms and that SEC_E error
|
||||
code is not a documented error for InitializeSecurityContext (digest).
|
||||
|
||||
https://github.com/curl/curl/issues/6302
|
||||
|
||||
6.10 curl never completes Negotiate over HTTP
|
||||
|
||||
Apparently it is not working correctly...?
|
||||
|
||||
See https://github.com/curl/curl/issues/5235
|
||||
|
||||
6.11 Negotiate on Windows fails
|
||||
|
||||
When using --negotiate (or NTLM) with curl on Windows, SSL/TLS handshake
|
||||
fails despite having a valid kerberos ticket cached. Works without any issue
|
||||
in Unix/Linux.
|
||||
|
||||
https://github.com/curl/curl/issues/5881
|
||||
|
||||
6.12 cannot use Secure Transport with Crypto Token Kit
|
||||
|
||||
https://github.com/curl/curl/issues/7048
|
||||
|
||||
6.13 Negotiate authentication against Hadoop HDFS
|
||||
|
||||
https://github.com/curl/curl/issues/8264
|
||||
|
||||
7. FTP
|
||||
|
||||
7.3 FTP with NOBODY and FAILONERROR
|
||||
|
||||
It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
|
||||
with FTP to detect if a file exists or not, but it is not working:
|
||||
https://curl.se/mail/lib-2008-07/0295.html
|
||||
|
||||
7.4 FTP with ACCT
|
||||
|
||||
When doing an operation over FTP that requires the ACCT command (but not when
|
||||
logging in), the operation will fail since libcurl does not detect this and
|
||||
thus fails to issue the correct command:
|
||||
https://curl.se/bug/view.cgi?id=635
|
||||
|
||||
7.11 FTPS upload data loss with TLS 1.3
|
||||
|
||||
During FTPS upload curl does not attempt to read TLS handshake messages sent
|
||||
after the initial handshake. OpenSSL servers running TLS 1.3 may send such a
|
||||
message. When curl closes the upload connection if unread data has been
|
||||
received (such as a TLS handshake message) then the TCP protocol sends an
|
||||
RST to the server, which may cause the server to discard or truncate the
|
||||
upload if it has not read all sent data yet, and then return an error to curl
|
||||
on the control channel connection.
|
||||
|
||||
Since 7.78.0 this is mostly fixed. curl will do a single read before closing
|
||||
TLS connections (which causes the TLS library to read handshake messages),
|
||||
however there is still possibility of an RST if more messages need to be read
|
||||
or a message arrives after the read but before close (network race condition).
|
||||
|
||||
https://github.com/curl/curl/issues/6149
|
||||
|
||||
7.12 FTPS directory listing hangs on Windows with Schannel
|
||||
|
||||
https://github.com/curl/curl/issues/9161
|
||||
|
||||
9. SFTP and SCP
|
||||
|
||||
9.1 SFTP does not do CURLOPT_POSTQUOTE correct
|
||||
|
||||
When libcurl sends CURLOPT_POSTQUOTE commands when connected to a SFTP server
|
||||
using the multi interface, the commands are not being sent correctly and
|
||||
instead the connection is "cancelled" (the operation is considered done)
|
||||
prematurely. There is a half-baked (busy-looping) patch provided in the bug
|
||||
report but it cannot be accepted as-is. See
|
||||
https://curl.se/bug/view.cgi?id=748
|
||||
|
||||
9.2 wolfssh: publickey auth does not work
|
||||
|
||||
When building curl to use the wolfSSH backend for SFTP, the publickey
|
||||
authentication does not work. This is simply functionality not written for curl
|
||||
yet, the necessary API for make this work is provided by wolfSSH.
|
||||
|
||||
See https://github.com/curl/curl/issues/4820
|
||||
|
||||
9.3 Remote recursive folder creation with SFTP
|
||||
|
||||
On this servers, the curl fails to create directories on the remote server
|
||||
even when the CURLOPT_FTP_CREATE_MISSING_DIRS option is set.
|
||||
|
||||
See https://github.com/curl/curl/issues/5204
|
||||
|
||||
9.4 libssh blocking and infinite loop problem
|
||||
|
||||
In the SSH_SFTP_INIT state for libssh, the ssh session working mode is set to
|
||||
blocking mode. If the network is suddenly disconnected during sftp
|
||||
transmission, curl will be stuck, even if curl is configured with a timeout.
|
||||
|
||||
https://github.com/curl/curl/issues/8632
|
||||
|
||||
|
||||
10. SOCKS
|
||||
|
||||
10.3 FTPS over SOCKS
|
||||
|
||||
libcurl does not support FTPS over a SOCKS proxy.
|
||||
|
||||
|
||||
11. Internals
|
||||
|
||||
11.1 Curl leaks .onion hostnames in DNS
|
||||
|
||||
Curl sends DNS requests for hostnames with a .onion TLD. This leaks
|
||||
information about what the user is attempting to access, and violates this
|
||||
requirement of RFC7686: https://datatracker.ietf.org/doc/html/rfc7686
|
||||
|
||||
Issue: https://github.com/curl/curl/issues/543
|
||||
|
||||
11.2 error buffer not set if connection to multiple addresses fails
|
||||
|
||||
If you ask libcurl to resolve a hostname like example.com to IPv6 addresses
|
||||
only. But you only have IPv4 connectivity. libcurl will correctly fail with
|
||||
CURLE_COULDNT_CONNECT. But the error buffer set by CURLOPT_ERRORBUFFER
|
||||
remains empty. Issue: https://github.com/curl/curl/issues/544
|
||||
|
||||
11.4 HTTP test server 'connection-monitor' problems
|
||||
|
||||
The 'connection-monitor' feature of the sws HTTP test server does not work
|
||||
properly if some tests are run in unexpected order. Like 1509 and then 1525.
|
||||
|
||||
See https://github.com/curl/curl/issues/868
|
||||
|
||||
11.5 Connection information when using TCP Fast Open
|
||||
|
||||
CURLINFO_LOCAL_PORT (and possibly a few other) fails when TCP Fast Open is
|
||||
enabled.
|
||||
|
||||
See https://github.com/curl/curl/issues/1332 and
|
||||
https://github.com/curl/curl/issues/4296
|
||||
|
||||
11.7 signal-based resolver timeouts
|
||||
|
||||
libcurl built without an asynchronous resolver library uses alarm() to time
|
||||
out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
|
||||
signal handler back into the library with a sigsetjmp, which effectively
|
||||
causes libcurl to continue running within the signal handler. This is
|
||||
non-portable and could cause problems on some platforms. A discussion on the
|
||||
problem is available at https://curl.se/mail/lib-2008-09/0197.html
|
||||
|
||||
Also, alarm() provides timeout resolution only to the nearest second. alarm
|
||||
ought to be replaced by setitimer on systems that support it.
|
||||
|
||||
11.10 Blocking socket operations in non-blocking API
|
||||
|
||||
The list of blocking socket operations is in TODO section "More non-blocking".
|
||||
|
||||
11.11 A shared connection cache is not thread-safe
|
||||
|
||||
The share interface offers CURL_LOCK_DATA_CONNECT to have multiple easy
|
||||
handle share a connection cache, but due to how connections are used they are
|
||||
still not thread-safe when used shared.
|
||||
|
||||
See https://github.com/curl/curl/issues/4915 and lib1541.c
|
||||
|
||||
11.15 CURLOPT_OPENSOCKETPAIRFUNCTION is missing
|
||||
|
||||
When libcurl creates sockets with socketpair(), those are not "exposed" in
|
||||
CURLOPT_OPENSOCKETFUNCTION and therefore might surprise and be unknown to
|
||||
applications that expect and want all sockets known beforehand. One way to
|
||||
address this issue is to introduce a CURLOPT_OPENSOCKETPAIRFUNCTION callback.
|
||||
|
||||
https://github.com/curl/curl/issues/5747
|
||||
|
||||
11.16 libcurl uses renames instead of locking for atomic operations
|
||||
|
||||
For saving cookies, alt-svc and hsts files. This is bad when for example the
|
||||
file is stored in a directory where the application has no write permission
|
||||
but it has permission for the file.
|
||||
|
||||
https://github.com/curl/curl/issues/6882
|
||||
https://github.com/curl/curl/pull/6884
|
||||
|
||||
12. LDAP
|
||||
|
||||
12.1 OpenLDAP hangs after returning results
|
||||
|
||||
By configuration defaults, OpenLDAP automatically chase referrals on
|
||||
secondary socket descriptors. The OpenLDAP backend is asynchronous and thus
|
||||
should monitor all socket descriptors involved. Currently, these secondary
|
||||
descriptors are not monitored, causing OpenLDAP library to never receive
|
||||
data from them.
|
||||
|
||||
As a temporary workaround, disable referrals chasing by configuration.
|
||||
|
||||
The fix is not easy: proper automatic referrals chasing requires a
|
||||
synchronous bind callback and monitoring an arbitrary number of socket
|
||||
descriptors for a single easy handle (currently limited to 5).
|
||||
|
||||
Generic LDAP is synchronous: OK.
|
||||
|
||||
See https://github.com/curl/curl/issues/622 and
|
||||
https://curl.se/mail/lib-2016-01/0101.html
|
||||
|
||||
12.2 LDAP on Windows does authentication wrong?
|
||||
|
||||
https://github.com/curl/curl/issues/3116
|
||||
|
||||
12.3 LDAP on Windows does not work
|
||||
|
||||
A simple curl command line getting "ldap://ldap.forumsys.com" returns an
|
||||
error that says "no memory" !
|
||||
|
||||
https://github.com/curl/curl/issues/4261
|
||||
|
||||
12.4 LDAPS with NSS is slow
|
||||
|
||||
See https://github.com/curl/curl/issues/5874
|
||||
|
||||
13. TCP/IP
|
||||
|
||||
13.2 Trying local ports fails on Windows
|
||||
|
||||
This makes '--local-port [range]' to not work since curl can't properly
|
||||
detect if a port is already in use, so it'll try the first port, use that and
|
||||
then subsequently fail anyway if that was actually in use.
|
||||
|
||||
https://github.com/curl/curl/issues/8112
|
||||
|
||||
15. CMake
|
||||
|
||||
15.2 support build with GnuTLS
|
||||
|
||||
15.3 unusable tool_hugehelp.c with MinGW
|
||||
|
||||
see https://github.com/curl/curl/issues/3125
|
||||
|
||||
15.4 build docs/curl.1
|
||||
|
||||
The cmake build does not create the docs/curl.1 file and therefore must rely on
|
||||
it being there already. This makes the --manual option not work and test
|
||||
cases like 1139 cannot function.
|
||||
|
||||
15.5 build on Linux links libcurl to libdl
|
||||
|
||||
... which it should not need to!
|
||||
|
||||
See https://github.com/curl/curl/issues/6165
|
||||
|
||||
15.6 uses -lpthread instead of Threads::Threads
|
||||
|
||||
See https://github.com/curl/curl/issues/6166
|
||||
|
||||
15.7 generated .pc file contains strange entries
|
||||
|
||||
The Libs.private field of the generated .pc file contains -lgcc -lgcc_s -lc
|
||||
-lgcc -lgcc_s
|
||||
|
||||
See https://github.com/curl/curl/issues/6167
|
||||
|
||||
15.8 libcurl.pc uses absolute library paths
|
||||
|
||||
The libcurl.pc file generated by cmake contains things like Libs.private:
|
||||
/usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The
|
||||
autotools equivalent would say Libs.private: -lssl -lcrypto -lz
|
||||
|
||||
See https://github.com/curl/curl/issues/6169
|
||||
|
||||
15.10 libpsl is not supported
|
||||
|
||||
See https://github.com/curl/curl/issues/6214
|
||||
|
||||
15.11 ExternalProject_Add does not set CURL_CA_PATH
|
||||
|
||||
CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's
|
||||
ExternalProject_Add is used to build curl as a dependency.
|
||||
|
||||
See https://github.com/curl/curl/issues/6313
|
||||
|
||||
15.13 CMake build with MIT Kerberos does not work
|
||||
|
||||
Minimum CMake version was bumped in curl 7.71.0 (#5358) Since CMake 3.2
|
||||
try_compile started respecting the CMAKE_EXE_FLAGS. The code dealing with
|
||||
MIT Kerberos detection sets few variables to potentially weird mix of space,
|
||||
and ;-separated flags. It had to blow up at some point. All the CMake checks
|
||||
that involve compilation are doomed from that point, the configured tree
|
||||
cannot be built.
|
||||
|
||||
https://github.com/curl/curl/issues/6904
|
||||
|
||||
16. Applications
|
||||
|
||||
17. HTTP/2
|
||||
|
||||
17.2 HTTP/2 frames while in the connection pool kill reuse
|
||||
|
||||
If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
|
||||
curl while the connection is held in curl's connection pool, the socket will
|
||||
be found readable when considered for reuse and that makes curl think it is
|
||||
dead and then it will be closed and a new connection gets created instead.
|
||||
|
||||
This is *best* fixed by adding monitoring to connections while they are kept
|
||||
in the pool so that pings can be responded to appropriately.
|
||||
|
||||
17.3 ENHANCE_YOUR_CALM causes infinite retries
|
||||
|
||||
Infinite retries with 2 parallel requests on one connection receiving GOAWAY
|
||||
with ENHANCE_YOUR_CALM error code.
|
||||
|
||||
See https://github.com/curl/curl/issues/5119
|
||||
|
||||
18. HTTP/3
|
||||
|
||||
18.1 If the HTTP/3 server closes connection during upload curl hangs
|
||||
|
||||
See https://github.com/curl/curl/issues/6606
|
||||
|
||||
18.2 Transfer closed with n bytes remaining to read
|
||||
|
||||
HTTP/3 transfers with the Jetty HTTP/3 server seem to not work.
|
||||
|
||||
https://github.com/curl/curl/issues/8523
|
||||
|
||||
18.4 timeout when reusing an http3 connection
|
||||
|
||||
HTTP/3 with quiche seems to not work and always timeout a subsequent transfer
|
||||
that reuses an already established connection
|
||||
|
||||
https://github.com/curl/curl/issues/8764
|
||||
|
||||
18.9 connection migration does not work
|
||||
|
||||
https://github.com/curl/curl/issues/7695
|
||||
@ -0,0 +1,285 @@
|
||||
_ _ ____ _
|
||||
___| | | | _ \| |
|
||||
/ __| | | | |_) | |
|
||||
| (__| |_| | _ <| |___
|
||||
\___|\___/|_| \_\_____|
|
||||
|
||||
MAIL ETIQUETTE
|
||||
|
||||
1. About the lists
|
||||
1.1 Mailing Lists
|
||||
1.2 Netiquette
|
||||
1.3 Do Not Mail a Single Individual
|
||||
1.4 Subscription Required
|
||||
1.5 Moderation of new posters
|
||||
1.6 Handling trolls and spam
|
||||
1.7 How to unsubscribe
|
||||
1.8 I posted, now what?
|
||||
1.9 Your emails are public
|
||||
|
||||
2. Sending mail
|
||||
2.1 Reply or New Mail
|
||||
2.2 Reply to the List
|
||||
2.3 Use a Sensible Subject
|
||||
2.4 Do Not Top-Post
|
||||
2.5 HTML is not for mails
|
||||
2.6 Quoting
|
||||
2.7 Digest
|
||||
2.8 Please Tell Us How You Solved The Problem
|
||||
|
||||
==============================================================================
|
||||
|
||||
1. About the lists
|
||||
|
||||
1.1 Mailing Lists
|
||||
|
||||
The mailing lists we have are all listed and described at
|
||||
https://curl.se/mail/
|
||||
|
||||
Each mailing list is targeted to a specific set of users and subjects,
|
||||
please use the one or the ones that suit you the most.
|
||||
|
||||
Each mailing list has hundreds up to thousands of readers, meaning that each
|
||||
mail sent will be received and read by a large number of people. People
|
||||
from various cultures, regions, religions and continents.
|
||||
|
||||
1.2 Netiquette
|
||||
|
||||
Netiquette is a common term for how to behave on the Internet. Of course, in
|
||||
each particular group and subculture there will be differences in what is
|
||||
acceptable and what is considered good manners.
|
||||
|
||||
This document outlines what we in the curl project consider to be good
|
||||
etiquette, and primarily this focus on how to behave on and how to use our
|
||||
mailing lists.
|
||||
|
||||
1.3 Do Not Mail a Single Individual
|
||||
|
||||
Many people send one question to one person. One person gets many mails, and
|
||||
there is only one person who can give you a reply. The question may be
|
||||
something that other people would also like to ask. These other people have
|
||||
no way to read the reply, but to ask the one person the question. The one
|
||||
person consequently gets overloaded with mail.
|
||||
|
||||
If you really want to contact an individual and perhaps pay for his or her
|
||||
services, by all means go ahead, but if it's just another curl question,
|
||||
take it to a suitable list instead.
|
||||
|
||||
1.4 Subscription Required
|
||||
|
||||
All curl mailing lists require that you are subscribed to allow a mail to go
|
||||
through to all the subscribers.
|
||||
|
||||
If you post without being subscribed (or from a different mail address than
|
||||
the one you are subscribed with), your mail will simply be silently
|
||||
discarded. You have to subscribe first, then post.
|
||||
|
||||
The reason for this unfortunate and strict subscription policy is of course
|
||||
to stop spam from pestering the lists.
|
||||
|
||||
1.5 Moderation of new posters
|
||||
|
||||
Several of the curl mailing lists automatically make all posts from new
|
||||
subscribers be moderated. This means that after you have subscribed and
|
||||
sent your first mail to a list, that mail will not be let through to the
|
||||
list until a mailing list administrator has verified that it is OK and
|
||||
permits it to get posted.
|
||||
|
||||
Once a first post has been made that proves the sender is actually talking
|
||||
about curl-related subjects, the moderation "flag" will be switched off and
|
||||
future posts will go through without being moderated.
|
||||
|
||||
The reason for this moderation policy is that we do suffer from spammers who
|
||||
actually subscribe and send spam to our lists.
|
||||
|
||||
1.6 Handling trolls and spam
|
||||
|
||||
Despite our good intentions and hard work to keep spam off the lists and to
|
||||
maintain a friendly and positive atmosphere, there will be times when spam
|
||||
and or trolls get through.
|
||||
|
||||
Troll - "someone who posts inflammatory, extraneous, or off-topic messages
|
||||
in an online community"
|
||||
|
||||
Spam - "use of electronic messaging systems to send unsolicited bulk
|
||||
messages"
|
||||
|
||||
No matter what, we NEVER EVER respond to trolls or spammers on the list. If
|
||||
you believe the list admin should do something in particular, contact them
|
||||
off-list. The subject will be taken care of as much as possible to prevent
|
||||
repeated offenses, but responding on the list to such messages never leads to
|
||||
anything good and only puts the light even more on the offender: which was
|
||||
the entire purpose of it getting sent to the list in the first place.
|
||||
|
||||
Do not feed the trolls.
|
||||
|
||||
1.7 How to unsubscribe
|
||||
|
||||
You can unsubscribe the same way you subscribed in the first place. You go
|
||||
to the page for the particular mailing list you are subscribed to and you enter
|
||||
your email address and password and press the unsubscribe button.
|
||||
|
||||
Also, the instructions to unsubscribe are included in the headers of every
|
||||
mail that is sent out to all curl related mailing lists and there's a footer
|
||||
in each mail that links to the "admin" page on which you can unsubscribe and
|
||||
change other options.
|
||||
|
||||
You NEVER EVER email the mailing list requesting someone else to take you off
|
||||
the list.
|
||||
|
||||
1.8 I posted, now what?
|
||||
|
||||
If you are not subscribed with the same email address that you used to send
|
||||
the email, your post will just be silently discarded.
|
||||
|
||||
If you posted for the first time to the mailing list, you first need to wait
|
||||
for an administrator to allow your email to go through (moderated). This
|
||||
normally happens quickly but in case we are asleep, you may have to wait a
|
||||
few hours.
|
||||
|
||||
Once your email goes through it is sent out to several hundred or even
|
||||
thousands of recipients. Your email may cover an area that not that many
|
||||
people know about or are interested in. Or possibly the person who knows
|
||||
about it is on vacation or under a heavy work load right now. You may have
|
||||
to wait for a response and you should not expect to get a response at all.
|
||||
Ideally, you get an answer within a couple of days.
|
||||
|
||||
You do yourself and all of us a service when you include as many details as
|
||||
possible already in your first email. Mention your operating system and
|
||||
environment. Tell us which curl version you are using and tell us what you
|
||||
did, what happened and what you expected would happen. Preferably, show us
|
||||
what you did with details enough to allow others to help point out the
|
||||
problem or repeat the steps in their locations.
|
||||
|
||||
Failing to include details will only delay responses and make people respond
|
||||
and ask for more details and you will have to send a follow-up email that
|
||||
includes them.
|
||||
|
||||
Expect the responses to primarily help YOU debug the issue, or ask YOU
|
||||
questions that can lead you or others towards a solution or explanation to
|
||||
whatever you experience.
|
||||
|
||||
If you are a repeat offender to the guidelines outlined in this document,
|
||||
chances are that people will ignore you at will and your chances to get
|
||||
responses in the future will greatly diminish.
|
||||
|
||||
1.9 Your emails are public
|
||||
|
||||
Your email, its contents and all its headers and the details in those
|
||||
headers will be received by every subscriber of the mailing list that you
|
||||
send your email to.
|
||||
|
||||
Your email as sent to a curl mailing list will end up in mail archives, on
|
||||
the curl website and elsewhere, for others to see and read. Today and in
|
||||
the future. In addition to the archives, the mail is sent out to thousands
|
||||
of individuals. There is no way to undo a sent email.
|
||||
|
||||
When sending emails to a curl mailing list, do not include sensitive
|
||||
information such as user names and passwords; use fake ones, temporary ones
|
||||
or just remove them completely from the mail. Note that this includes base64
|
||||
encoded HTTP Basic auth headers.
|
||||
|
||||
This public nature of the curl mailing lists makes automatically inserted mail
|
||||
footers about mails being "private" or "only meant for the recipient" or
|
||||
similar even more silly than usual. Because they are absolutely not private
|
||||
when sent to a public mailing list.
|
||||
|
||||
|
||||
2. Sending mail
|
||||
|
||||
2.1 Reply or New Mail
|
||||
|
||||
Please do not reply to an existing message as a short-cut to post a message
|
||||
to the lists.
|
||||
|
||||
Many mail programs and web archivers use information within mails to keep
|
||||
them together as "threads", as collections of posts that discuss a certain
|
||||
subject. If you do not intend to reply on the same or similar subject, do not
|
||||
just hit reply on an existing mail and change the subject, create a new mail.
|
||||
|
||||
2.2 Reply to the List
|
||||
|
||||
When replying to a message from the list, make sure that you do "group
|
||||
reply" or "reply to all", and not just reply to the author of the single
|
||||
mail you reply to.
|
||||
|
||||
We are actively discouraging replying back to the single person by setting
|
||||
the Reply-To: field in outgoing mails back to the mailing list address,
|
||||
making it harder for people to mail the author directly, if only by mistake.
|
||||
|
||||
2.3 Use a Sensible Subject
|
||||
|
||||
Please use a subject of the mail that makes sense and that is related to the
|
||||
contents of your mail. It makes it a lot easier to find your mail afterwards
|
||||
and it makes it easier to track mail threads and topics.
|
||||
|
||||
2.4 Do Not Top-Post
|
||||
|
||||
If you reply to a message, do not use top-posting. Top-posting is when you
|
||||
write the new text at the top of a mail and you insert the previous quoted
|
||||
mail conversation below. It forces users to read the mail in a backwards
|
||||
order to properly understand it.
|
||||
|
||||
This is why top posting is so bad (in top posting order):
|
||||
|
||||
A: Because it messes up the order in which people normally read text.
|
||||
Q: Why is top-posting such a bad thing?
|
||||
A: Top-posting.
|
||||
Q: What is the most annoying thing in email?
|
||||
|
||||
Apart from the screwed up read order (especially when mixed together in a
|
||||
thread when someone responds using the mandated bottom-posting style), it
|
||||
also makes it impossible to quote only parts of the original mail.
|
||||
|
||||
When you reply to a mail. You let the mail client insert the previous mail
|
||||
quoted. Then you put the cursor on the first line of the mail and you move
|
||||
down through the mail, deleting all parts of the quotes that do not add
|
||||
context for your comments. When you want to add a comment you do so, inline,
|
||||
right after the quotes that relate to your comment. Then you continue
|
||||
downwards again.
|
||||
|
||||
When most of the quotes have been removed and you have added your own words,
|
||||
you are done.
|
||||
|
||||
2.5 HTML is not for mails
|
||||
|
||||
Please switch off those HTML encoded messages. You can mail all those funny
|
||||
mails to your friends. We speak plain text mails.
|
||||
|
||||
2.6 Quoting
|
||||
|
||||
Quote as little as possible. Just enough to provide the context you cannot
|
||||
leave out. A lengthy description can be found here:
|
||||
|
||||
https://www.netmeister.org/news/learn2quote.html
|
||||
|
||||
2.7 Digest
|
||||
|
||||
We allow subscribers to subscribe to the "digest" version of the mailing
|
||||
lists. A digest is a collection of mails lumped together in one single mail.
|
||||
|
||||
Should you decide to reply to a mail sent out as a digest, there are two
|
||||
things you MUST consider if you really really cannot subscribe normally
|
||||
instead:
|
||||
|
||||
Cut off all mails and chatter that is not related to the mail you want to
|
||||
reply to.
|
||||
|
||||
Change the subject name to something sensible and related to the subject,
|
||||
preferably even the actual subject of the single mail you wanted to reply to
|
||||
|
||||
2.8 Please Tell Us How You Solved The Problem
|
||||
|
||||
Many people mail questions to the list, people spend some of their time and
|
||||
make an effort in providing good answers to these questions.
|
||||
|
||||
If you are the one who asks, please consider responding once more in case
|
||||
one of the hints was what solved your problems. The guys who write answers
|
||||
feel good to know that they provided a good answer and that you fixed the
|
||||
problem. Far too often, the person who asked the question is never heard from
|
||||
again, and we never get to know if they are gone because the problem was
|
||||
solved or perhaps because the problem was unsolvable.
|
||||
|
||||
Getting the solution posted also helps other users that experience the same
|
||||
problem(s). They get to see (possibly in the web archives) that the
|
||||
suggested fixes actually have helped at least one person.
|
||||
@ -0,0 +1,27 @@
|
||||
# MQTT in curl
|
||||
|
||||
## Usage
|
||||
|
||||
A plain "GET" subscribes to the topic and prints all published messages.
|
||||
Doing a "POST" publishes the post data to the topic and exits.
|
||||
|
||||
Example subscribe:
|
||||
|
||||
curl mqtt://host/home/bedroom/temp
|
||||
|
||||
Example publish:
|
||||
|
||||
curl -d 75 mqtt://host/home/bedroom/dimmer
|
||||
|
||||
## What does curl deliver as a response to a subscribe
|
||||
|
||||
It outputs two bytes topic length (MSB | LSB), the topic followed by the
|
||||
payload.
|
||||
|
||||
## Caveats
|
||||
|
||||
Remaining limitations:
|
||||
- Only QoS level 0 is implemented for publish
|
||||
- No way to set retain flag for publish
|
||||
- No TLS (mqtts) support
|
||||
- Naive EAGAIN handling will not handle split messages
|
||||
@ -0,0 +1,110 @@
|
||||
# Adding a new protocol?
|
||||
|
||||
Every once in a while, someone comes up with the idea of adding support for yet
|
||||
another protocol to curl. After all, curl already supports 25 something
|
||||
protocols and it is the Internet transfer machine for the world.
|
||||
|
||||
In the curl project we love protocols and we love supporting many protocols
|
||||
and doing it well.
|
||||
|
||||
So how do you proceed to add a new protocol and what are the requirements?
|
||||
|
||||
## No fixed set of requirements
|
||||
|
||||
This document is an attempt to describe things to consider. There is no
|
||||
checklist of the twenty-seven things you need to cross off. We view the entire
|
||||
effort as a whole and then judge if it seems to be the right thing - for
|
||||
now. The more things that look right, fit our patterns and are done in ways
|
||||
that align with our thinking, the better are the chances that we will agree
|
||||
that supporting this protocol is a grand idea.
|
||||
|
||||
## Mutual benefit is preferred
|
||||
|
||||
curl is not here for your protocol. Your protocol is not here for curl. The
|
||||
best cooperation and end result occur when all involved parties mutually see
|
||||
and agree that supporting this protocol in curl would be good for everyone.
|
||||
Heck, for the world.
|
||||
|
||||
Consider "selling us" the idea that we need an implementation merged in curl,
|
||||
to be fairly important. *Why* do we want curl to support this new protocol?
|
||||
|
||||
## Protocol requirements
|
||||
|
||||
### Client-side
|
||||
|
||||
The protocol implementation is for a client's side of a "communication
|
||||
session".
|
||||
|
||||
### Transfer oriented
|
||||
|
||||
The protocol itself should be focused on *transfers*. Be it uploads or
|
||||
downloads or both. It should at least be possible to view the transfers as
|
||||
such, like we can view reading emails over POP3 as a download and sending
|
||||
emails over SMTP as an upload.
|
||||
|
||||
If you cannot even shoehorn the protocol into a transfer focused view, then
|
||||
you are up for a tough argument.
|
||||
|
||||
### URL
|
||||
|
||||
There should be a documented URL format. If there is an RFC for it there is no
|
||||
question about it but the syntax does not have to be a published RFC. It could
|
||||
be enough if it is already in use by other implementations.
|
||||
|
||||
If you make up the syntax just in order to be able to propose it to curl, then
|
||||
you are in a bad place. URLs are designed and defined for interoperability.
|
||||
There should at least be a good chance that other clients and servers can be
|
||||
implemented supporting the same URL syntax and work the same or similar way.
|
||||
|
||||
URLs work on registered 'schemes'. There is a register of [all officially
|
||||
recognized
|
||||
schemes](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml). If
|
||||
your protocol is not in there, is it really a protocol we want?
|
||||
|
||||
### Wide and public use
|
||||
|
||||
The protocol shall already be used or have an expectation of getting used
|
||||
widely. Experimental protocols are better off worked on in experiments first,
|
||||
to prove themselves before they are adopted by curl.
|
||||
|
||||
## Code
|
||||
|
||||
Of course the code needs to be written, provided, licensed agreeably and it
|
||||
should follow our code guidelines and review comments have to be dealt with.
|
||||
If the implementation needs third party code, that third party code should not
|
||||
have noticeably lesser standards than the curl project itself.
|
||||
|
||||
## Tests
|
||||
|
||||
As much of the protocol implementation as possible needs to be verified by
|
||||
curl test cases. We must have the implementation get tested by CI jobs,
|
||||
torture tests and more.
|
||||
|
||||
We have experienced many times in the past how new implementations were brought
|
||||
to curl and immediately once the code had been merged, the originator vanished
|
||||
from the face of the earth. That is fine, but we need to take the necessary
|
||||
precautions so when it happens we are still fine.
|
||||
|
||||
Our test infrastructure is powerful enough to test just about every possible
|
||||
protocol - but it might require a bit of an effort to make it happen.
|
||||
|
||||
## Documentation
|
||||
|
||||
We cannot assume that users are particularly familiar with details and
|
||||
peculiarities of the protocol. It needs documentation.
|
||||
|
||||
Maybe it even needs some internal documentation so that the developers who
|
||||
will try to debug something five years from now can figure out functionality a
|
||||
little easier!
|
||||
|
||||
The protocol specification itself should be freely available without requiring
|
||||
a non-disclosure agreement or similar.
|
||||
|
||||
## Do not compare
|
||||
|
||||
We are constantly raising the bar and we are constantly improving the
|
||||
project. A lot of things we did in the past would not be acceptable if done
|
||||
today. Therefore, you might be tempted to use shortcuts or "hacks" you can
|
||||
spot other - existing - protocol implementations have used, but there is
|
||||
nothing to gain from that. The bar has been raised. Former "cheats" will not be
|
||||
tolerated anymore.
|
||||
@ -0,0 +1,50 @@
|
||||
# Parallel transfers
|
||||
|
||||
curl 7.66.0 introduced support for doing multiple transfers simultaneously; in
|
||||
parallel.
|
||||
|
||||
## -Z, --parallel
|
||||
|
||||
When this command line option is used, curl will perform the transfers given
|
||||
to it at the same time. It will do up to `--parallel-max` concurrent
|
||||
transfers, with a default value of 50.
|
||||
|
||||
## Progress meter
|
||||
|
||||
The progress meter that is displayed when doing parallel transfers is
|
||||
completely different than the regular one used for each single transfer.
|
||||
|
||||
It shows:
|
||||
|
||||
o percent download (if known, which means *all* transfers need to have a
|
||||
known size)
|
||||
o percent upload (if known, with the same caveat as for download)
|
||||
o total amount of downloaded data
|
||||
o total amount of uploaded data
|
||||
o number of transfers to perform
|
||||
o number of concurrent transfers being transferred right now
|
||||
o number of transfers queued up waiting to start
|
||||
o total time all transfers are expected to take (if sizes are known)
|
||||
o current time the transfers have spent so far
|
||||
o estimated time left (if sizes are known)
|
||||
o current transfer speed (the faster of upload/download speeds measured over
|
||||
the last few seconds)
|
||||
|
||||
Example:
|
||||
|
||||
DL% UL% Dled Uled Xfers Live Qd Total Current Left Speed
|
||||
72 -- 37.9G 0 101 30 23 0:00:55 0:00:34 0:00:22 2752M
|
||||
|
||||
## Behavior differences
|
||||
|
||||
Connections are shared fine between different easy handles, but the
|
||||
"authentication contexts" are not. So for example doing HTTP Digest auth with
|
||||
one handle for a particular transfer and then continue on with another handle
|
||||
that reuses the same connection, the second handle cannot send the necessary
|
||||
Authorization header at once since the context is only kept in the original
|
||||
easy handle.
|
||||
|
||||
To fix this, the authorization state could be made possible to share with the
|
||||
share API as well, as a context per origin + path (realm?) basically.
|
||||
|
||||
Visible in test 153, 1412 and more.
|
||||
@ -0,0 +1,12 @@
|
||||
|
||||
|
||||
# Documentation
|
||||
|
||||
you will find a mix of various documentation in this directory and
|
||||
subdirectories, using several different formats. Some of them are not ideal
|
||||
for reading directly in your browser.
|
||||
|
||||
If you would rather see the rendered version of the documentation, check out the
|
||||
curl website's [documentation section](https://curl.se/docs/) for
|
||||
general curl stuff or the [libcurl section](https://curl.se/libcurl/) for
|
||||
libcurl related documentation.
|
||||
@ -0,0 +1,117 @@
|
||||
curl release procedure - how to do a release
|
||||
============================================
|
||||
|
||||
in the source code repo
|
||||
-----------------------
|
||||
|
||||
- run `./scripts/copyright.pl` and correct possible omissions
|
||||
|
||||
- edit `RELEASE-NOTES` to be accurate
|
||||
|
||||
- update `docs/THANKS`
|
||||
|
||||
- make sure all relevant changes are committed on the master branch
|
||||
|
||||
- tag the git repo in this style: `git tag -a curl-7_34_0`. -a annotates the
|
||||
tag and we use underscores instead of dots in the version number. Make sure
|
||||
the tag is GPG signed (using -s).
|
||||
|
||||
- run `./maketgz 7.34.0` to build the release tarballs. It is important that
|
||||
you run this on a machine with the correct set of autotools etc installed
|
||||
as this is what then will be shipped and used by most users on \*nix like
|
||||
systems.
|
||||
|
||||
- push the git commits and the new tag
|
||||
|
||||
- GPG sign the 4 tarballs as `maketgz` suggests
|
||||
|
||||
- upload the 8 resulting files to the primary download directory
|
||||
|
||||
in the curl-www repo
|
||||
--------------------
|
||||
|
||||
- edit `Makefile` (version number and date),
|
||||
|
||||
- edit `_newslog.html` (announce the new release) and
|
||||
|
||||
- edit `_changes.html` (insert changes+bugfixes from RELEASE-NOTES)
|
||||
|
||||
- commit all local changes
|
||||
|
||||
- tag the repo with the same name as used for the source repo.
|
||||
|
||||
- make sure all relevant changes are committed and pushed on the master branch
|
||||
|
||||
(the website then updates its contents automatically)
|
||||
|
||||
on GitHub
|
||||
---------
|
||||
|
||||
- edit the newly made release tag so that it is listed as the latest release
|
||||
|
||||
inform
|
||||
------
|
||||
|
||||
- send an email to curl-users, curl-announce and curl-library. Insert the
|
||||
RELEASE-NOTES into the mail.
|
||||
|
||||
celebrate
|
||||
---------
|
||||
|
||||
- suitable beverage intake is encouraged for the festivities
|
||||
|
||||
curl release scheduling
|
||||
=======================
|
||||
|
||||
Release Cycle
|
||||
-------------
|
||||
|
||||
We do releases every 8 weeks on Wednesdays. If critical problems arise, we can
|
||||
insert releases outside of the schedule or we can move the release date - but
|
||||
this is rare.
|
||||
|
||||
Each 8 week release cycle is split in two 4-week periods.
|
||||
|
||||
- During the first 4 weeks after a release, we allow new features and changes
|
||||
to curl and libcurl. If we accept any such changes, we bump the minor number
|
||||
used for the next release.
|
||||
|
||||
- During the second 4-week period we do not merge any features or changes, we
|
||||
then only focus on fixing bugs and polishing things to make a solid coming
|
||||
release.
|
||||
|
||||
- After a regular procedure-following release (made on Wednesdays), the
|
||||
feature window remains closed until the following Monday in case of special
|
||||
actions or patch releases etc.
|
||||
|
||||
If a future release date happens to end up on a "bad date", like in the middle
|
||||
of common public holidays or when the lead release manager is away traveling,
|
||||
the release date can be moved forwards or backwards a full week. This is then
|
||||
advertised well in advance.
|
||||
|
||||
Critical problems
|
||||
-----------------
|
||||
|
||||
We can break the release cycle and do a patch release at any point if a
|
||||
critical enough problem is reported. There is no exact definition of how to
|
||||
assess such criticality, but if an issue is highly disturbing or has a
|
||||
security impact on a large enough share of the user population it might
|
||||
qualify.
|
||||
|
||||
If you think an issue qualifies, bring it to the curl-library mailing list and
|
||||
push for it.
|
||||
|
||||
Coming dates
|
||||
------------
|
||||
|
||||
Based on the description above, here are some planned release dates (at the
|
||||
time of this writing):
|
||||
|
||||
- March 20, 2023 (8.0.0 - curl 25 years)
|
||||
- May 17, 2023
|
||||
- July 19, 2023
|
||||
- September 6, 2023
|
||||
- November 1, 2023
|
||||
- December 27, 2023
|
||||
- February 21, 2024
|
||||
- April 17, 2024
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче