edg-l/ddnet
1
0
Fork 0
mirror of https://github.com/ddnet/ddnet.git synced 2024-11-14 03:58:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
ddnet/src/base/hash_ctxt.h

37 lines
781 B
C
Raw Normal View History

Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#ifndef BASE_HASH_CTXT_H
#define BASE_HASH_CTXT_H
#include "hash.h"
Use (u)int64 from system.h instead of (u)int64_t from cstdint src/game/client/prediction/gameworld.h:62:90: error: ‘int64_t’ has not been declared 62 | void CreateExplosion(vec2 Pos, int Owner, int Weapon, bool NoDamage, int ActivatedTeam, int64_t Mask); | ^~~~~~~
2020-07-08 14:59:32 +00:00
#include "system.h"
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#include <stdint.h>
#if defined(CONF_OPENSSL)
Use OpenSSL md5 if it is available Fixes #1582.
2019-04-06 00:46:56 +00:00
#include <openssl/md5.h>
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#include <openssl/sha.h>
Use OpenSSL md5 if it is available Fixes #1582.
2019-04-06 00:46:56 +00:00
#else
#include <engine/external/md5/md5.h>
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#endif
#if defined(CONF_OPENSSL)
// SHA256_CTX is defined in <openssl/sha.h>
#else
typedef struct
{
uint64 -> uint64_t, int64 -> int64_t
2021-06-23 05:05:49 +00:00
uint64_t length;
Run clang-format Purely automatic change. In case of conflict with this change, apply the other change and rerun the formatting to restore it: $ python scripts/fix_style.py
2020-09-26 19:41:58 +00:00
uint32_t state[8];
uint32_t curlen;
unsigned char buf[64];
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
} SHA256_CTX;
Use OpenSSL md5 if it is available Fixes #1582.
2019-04-06 00:46:56 +00:00
typedef md5_state_t MD5_CTX;
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#endif
void sha256_init(SHA256_CTX *ctxt);
void sha256_update(SHA256_CTX *ctxt, const void *data, size_t data_len);
SHA256_DIGEST sha256_finish(SHA256_CTX *ctxt);
Use OpenSSL md5 if it is available Fixes #1582.
2019-04-06 00:46:56 +00:00
void md5_init(MD5_CTX *ctxt);
void md5_update(MD5_CTX *ctxt, const void *data, size_t data_len);
MD5_DIGEST md5_finish(MD5_CTX *ctxt);
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#endif // BASE_HASH_CTXT_H
Reference in a new issue Copy permalink