mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/Types/Group.hs

41 lines
834 B
Haskell
Raw Normal View History

group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
{- git-annex repo groups
-
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized.
2024-08-10 20:32:54 +00:00
- Copyright 2012-2024 Joey Hess <id@joeyh.name>
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
-
update licenses from GPL to AGPL This does not change the overall license of the git-annex program, which was already AGPL due to a number of sources files being AGPL already. Legally speaking, I'm adding a new license under which these files are now available; I already released their current contents under the GPL license. Now they're dual licensed GPL and AGPL. However, I intend for all my future changes to these files to only be released under the AGPL license, and I won't be tracking the dual licensing status, so I'm simply changing the license statement to say it's AGPL. (In some cases, others wrote parts of the code of a file and released it under the GPL; but in all cases I have contributed a significant portion of the code in each file and it's that code that is getting the AGPL license; the GPL license of other contributors allows combining with AGPL code.)
2019-03-13 19:48:14 +00:00
- Licensed under the GNU AGPL version 3 or higher.
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
-}
module Types.Group (
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster.
2019-01-09 19:00:43 +00:00
Group(..),
fromGroup,
toGroup,
add --ingroup limit
2012-10-08 19:18:58 +00:00
GroupMap(..),
emptyGroupMap
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
) where
import Types.UUID
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster.
2019-01-09 19:00:43 +00:00
import Utility.FileSystemEncoding
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized.
2024-08-10 20:32:54 +00:00
import Annex.Balanced
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
import qualified Data.Map as M
import qualified Data.Set as S
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster.
2019-01-09 19:00:43 +00:00
import qualified Data.ByteString as S
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster.
2019-01-09 19:00:43 +00:00
newtype Group = Group S.ByteString
convert old uuid-based log parsers to attoparsec This preserves the workaround for the old bug that caused NoUUID items to be stored in the log, prefixing log lines with " ". It's now handled implicitly, by using takeWhile1 (/= ' ') to get the uuid. There is a behavior change from the old parser, which split the value into words and then recombined it. That meant that "foo bar" and "foo\tbar" came out as "foo bar". That behavior was not documented, and seems surprising; it meant that after a git-annex describe here "foo bar", you wouldn't get that same string back out when git-annex displayed repo descriptions. Otoh, some other parsers relied on the old behavior, and the attoparsec rewrites had to deal with the issue themselves... For group.log, there are some edge cases around the user providing a group name with a leading or trailing space. The old parser would ignore such excess whitespace. The new parser does too, because the alternative is to refuse to parse something like " group1 group2 " due to excess whitespace, which would be even more confusing behavior. The only git-annex branch log file that is not converted to attoparsec and bytestring-builder now is transitions.log.
2019-01-10 18:39:36 +00:00
deriving (Eq, Ord, Show)
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster.
2019-01-09 19:00:43 +00:00
fromGroup :: Group -> String
fromGroup (Group g) = decodeBS g
toGroup :: String -> Group
toGroup = Group . encodeBS
group, ungroup: New commands to indicate groups of repositories.
2012-10-01 19:12:04 +00:00
status: display repository groups
2012-10-02 17:45:30 +00:00
data GroupMap = GroupMap
{ groupsByUUID :: M.Map UUID (S.Set Group)
, uuidsByGroup :: M.Map Group (S.Set UUID)
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized.
2024-08-10 20:32:54 +00:00
, balancedPickerByGroup :: M.Map Group BalancedPicker
status: display repository groups
2012-10-02 17:45:30 +00:00
}
add --ingroup limit
2012-10-08 19:18:58 +00:00
emptyGroupMap :: GroupMap
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized.
2024-08-10 20:32:54 +00:00
emptyGroupMap = GroupMap M.empty M.empty M.empty
Reference in a new issue Copy permalink