I have a .snyk file with a number of entries like these:
'snyk:lic:maven:org.clojure:tools.analyzer.jvm:EPL-1.0':
- '*':
reason: 'ignore license issue'
expires: '2100-01-15T00:00:000Z'
'snyk:lic:maven:org.clojure:tools.analyzer:EPL-1.0':
- '*':
reason: 'ignore license issue'
expires: '2100-01-15T00:00:000Z'
These entries match the first example shown in Snyk's CLI Ignore docs.
Is there a more concise way to ignore all issues for a single license type (EPL-1.0 in this case)?
Related
Consider the use case where we need to find the pattern for a attack like 10 failed logons from the same device and same username followed by a success logon from different device but same username. This should happen within 10 mins.
Let us say we have 10 login failed windows events with user A as username and B as devicename and we have a success logon from user A with different device C, we should raise an alert. Please let me know how flink CEP can be used to solve the case.
This is rather similar to Apache Flink - Matching Fields with the same value. In this case you might try MATCH_RECOGNIZE with something this:
PARTITION BY user
...
PATTERN (F{10} S) WITHIN INTERVAL '10' MINUTE
DEFINE
F.status = 'failure' AND (LAST(F.device, 1) IS NULL OR F.device = LAST(F.device, 1)),
S AS S.status = 'success' AND S.device <> LAST(F.device, 1)
The idea is to check that each new F is for the same device as the previous one, and S is for a different device.
BTW, in practice you might rather specify F{10,} so that the pattern matches 10 or more failed attempts in a row, rather than exactly 10.
For ROS recipes, recipes contain a license extracted from an XML and line is indicated in the recipe:
For example, for XMLRCPP:
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://package.xml;beginline=11;endline=11;md5=184dd1523b9a109aead3fbbe0b4262e0"
But Ar-track-alvar has the same license name but a different MD5:
LICENSE = "LGPL-2.1"
LIC_FILES_CHKSUM = "file://package.xml;beginline=10;endline=10;md5=061abe8dc89f326789675967c8760541"
Hence, how is this MD5 calculated if the strings are the same?
EDIT: #jku explained the reason and how it works. The simple explanation is that the second package.xml has 2 whitespaces at start
If the checksums are different, then the strings are not the same. The difference could be just whitespace or different copyright years.
The purpose of LIC_FILES_CHECKSUM isn't to ensure that the license really is what it claims to be (because that's not practically possible). Instead it's used to make sure the license does not change without the recipe maintainer noticing when the recipe version is updated.
Most important
DB Unit returns a difference for a double value in row 78:
Exception in thread "main" junit.framework.ComparisonFailure: value (table=dataset, row=78, col=DirtyValue) expected:<4901232.27291950[7]> but was:<4901232.27291950[6]>
So I assume that SQL Server returns 4901232.272919507 while HANA returns 4901232.272919506
(Based on the answer to JUnit assertEquals Changes String)
Then I tried to set the tolerated delta acording to the FAQ Is there an equivalent to JUnit's assertEquals(double expected, double actual, double delta) to define a tolerance level when comparing numeric values?
But I do still get the same error - any ideas?
Additional information
Maybe this is the reason:?
[main] WARN org.dbunit.dataset.AbstractTableMetaData - Potential problem found: The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'Microsoft SQL Server' (e.g. some datatypes may not be supported properly). In rare cases you might see this message because the list of supported database products is incomplete (list=[derby]). If so please request a java-class update via the forums.If you are using your own IDataTypeFactory extending DefaultDataTypeFactory, ensure that you override getValidDbProducts() to specify the supported database products.
[main] WARN org.dbunit.dataset.AbstractTableMetaData - Potential problem found: The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'HDB' (e.g. some datatypes may not be supported properly). In rare cases you might see this message because the list of supported database products is incomplete (list=[derby]). If so please request a java-class update via the forums.If you are using your own IDataTypeFactory extending DefaultDataTypeFactory, ensure that you override getValidDbProducts() to specify the supported database products.
DbUnit Version 2.5.4
DirtyValue is calculated from 3 double vales in both systems
SQL Server
SELECT TypeOfGroup, Segment, Portfolio, UniqueID, JobId, DirtyValue, PosUnits, FX_RATE, THEO_Value
FROM DATASET_PL
order by JobId, TypeOfGroup, Segment, Portfolio, UniqueID COLLATE Latin1_General_bin
HANA
SELECT "TypeOfGroup", "Segment", "Portfolio", "UniqueID", "JobId", "DirtyValue", Pos_Units as "PosUnits", FX_RATE, THEO_Value as "THEO_Value"
FROM "_SYS_BIC"."meag.app.h4q.metadata.dataset.pnl/06_COMPARE_CUBES_AND_CALC_ATTR"
order by "JobId", "TypeOfGroup", "Segment", "Portfolio", "UniqueID"
Work-around
Use a diffhandler and handle the differences there:
DiffCollectingFailureHandler diffHandler = new DiffCollectingFailureHandler();
Assertion.assertEquals(expectedTable, actualTable);
List<Difference> diffList = diffHandler.getDiffList();
for (Difference diff: diffList) {
if (diff.getColumnName().equals("DirtyValue")) {
double actual = (double) diff.getActualValue();
double expected = (double) diff.getExpectedValue();
if (Math.abs(Math.abs(actual) - Math.abs(expected)) > 0.00001) {
logDiff(diff);
} else {
logDebugDiff(diff);
}
} else {
logDiff(diff);
}
}
private void logDiff(Difference diff) {
logger.error(String.format("Diff found in row:%s, col:%s expected:%s, actual:%s", diff.getRowIndex(), diff.getColumnName(), diff.getExpectedValue(), diff.getActualValue()));
}
private void logDebugDiff(Difference diff) {
logger.debug(String.format("Diff found in row:%s, col:%s expected:%s, actual:%s", diff.getRowIndex(), diff.getColumnName(), diff.getExpectedValue(), diff.getActualValue()));
}
The question was "Any idea?", so maybe it helps to understand why the difference occurrs.
HANA truncates if needed, see "HANA SQL and System Views Reference", numeric types. In HANA the following Statement results in 123.45:
select cast( '123.456' as decimal(6,2)) from dummy;
SQL-Server rounds if needed, at least if the target data type is numeric, see e.g. here at "Truncating and rounding results".
The same SQL statement as above results in 123.46 in SQL-Server.
And SQL-Standard seems to leave it open, whether to round or to truncate, see answer on SO .
I am not aware of any settings that change the rounding behavior in HANA, but maybe there is.
My package needs to set up some SELinux rules to allow my program access to certain things. Although I know which types I need to use in setting up the rules, I'm not sure which packages install those types. I would like to make sure that my package has dependencies on the SELinux types I reference. Is there a way I can find out which package was responsible for installing a given SELinux type?
In this specific case I'm looking for unconfined_service_t, but a general solution would be great because I'm sure I'll hit this again.
SELinux modules are in /usr/share/selinux/targeted/ directory.
You must guess (more about this later) which file it may be.
# cp /etc/selinux/targeted/modules/active/modules/cdrecord.pp /tmp
# file cdrecord.pp
cdrecord.pp: bzip2 compressed data, block size = 900k
# bunzip2 cdrecord.pp
bunzip2: Can't guess original name for cdrecord.pp -- using cdrecord.pp.out
# dnf install checkpolicy
...
# sedismod cdrecord.pp.out
Reading policy...
libsepol.policydb_index_others: security: 0 users, 3 roles, 42 types, 3 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security: 51 classes, 0 rules, 0 cond rules
libsepol.policydb_index_others: security: 0 users, 3 roles, 42 types, 3 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security: 51 classes, 0 rules, 0 cond rules
Binary policy module file loaded.
Module name: cdrecord
Module version: 2.6.0
Select a command:
1) display unconditional AVTAB
2) display conditional AVTAB
3) display users
4) display bools
5) display roles
6) display types, attributes, and aliases
7) display role transitions
8) display role allows
9) Display policycon
0) Display initial SIDs
a) Display avrule requirements
b) Display avrule declarations
c) Display policy capabilities
l) Link in a module
u) Display the unknown handling setting
F) Display filename_trans rules
f) set output file
m) display menu
q) quit
Command ('m' for menu): 6
...
staff_cdrecord_t [1]: alias for type cdrecord_t flags:0
...
Let say that staff_cdrecord_t was the one which interested us. Hurray!
Now just query which package provide it:
# rpm -qf /etc/selinux/targeted/modules/active/modules/cdrecord.pp
selinux-policy-targeted-3.13.1-105.20.fc21.noarch
So the only question is what file from /etc/selinux/targeted/modules/active/modules/ you query. Well you either have to go one by one (unless somebody knows some way, which is scriptable) or you have to use common sense. When I look for staff_cdrecord_t, I would start with cdrecord.pp.
I'm a little confused by these two terms: "Legacy Distinguished Name"(Legacy DN) and "Distingushed Name"(DN).
The first term Legacy DN seems only for Exchange, while the latter DN is only mentioned for Active Directory.
They are obviously not in same format:
DN is like: CN=Morgan Cheng, OU= SomeOrg, DC=SomeCom, DC=com
LegacyDN is like: /o=SomeDomain/ou=SomeGroup/cn=Recipients/cn=Morgan Cheng
I am still not clear what exactly the differce is. Are they two totally differnt stuff? or just same info represented in two different forms?
And, why is it called "Legacy"? If it is legacy, something must be new, right?
Hope some AD and Exchang experts can give me some inputs.
In Exchange 5.5, Exchange was assigning distinguished names to accounts and mailboxes (Obj-Dist-Name). When Active Directory came along, Exchange 2000 and later would use its distinguished names instead. In order to preserve backwards compatibility, migration from Exchange 5.5 to Exchange 2000 carried over the old DNs into the legacyExchangeDN attribute of ActiveDirectory.
Some applications continue to refer to Obj-Dist-Name. To preserve compatibility with these applications, later exchange versions synthesize a legacyExchangeDN value even for objects that have not been migrated from Exchange 5.5. The RUS automatically sets it to some value, apparently to the same value as the distinguishedName in your case.
The "new" way (since 2000) is to refer to objects by distinguished name, not Obj-Dist-Name.