We convert ASN1 time via std::tm to int64_t representing milliseconds-since-epoch. We do not use time_t since that cannot store milliseconds, and expires for 32-bit platforms in 2038 also for seconds.
Conversion via std::tm might might seem silly, but actually doesn't add any complexity.
One would expect tm -> seconds-since-epoch to already exist on the standard library. There is mktime, but it uses localtime (and sets an environment variable, and has the 2038 problem).
The ASN1 TIME parsing is limited to what is required by RFC 5280.
BUG=webrtc:5150
R=hbos@webrtc.org, nisse@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1468273004 .
Cr-Commit-Position: refs/heads/master@{#10854}
Added to prevent Chromium from breaking if KeyType (now an enum) starts being used in Chromium before KeyType changes to a parameterizable class. When enum -> class change happens, IntKeyTypeFamilyToKeyType will be updated at the same time.
Once Chromium starts using class KeyType with parameters this function can be removed.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1363543002 .
Cr-Commit-Position: refs/heads/master@{#10013}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
This CL allows you to, having generated one or more RTCCertificates, supply them to RTCConfiguration for CreatePeerConnection use. This means an SSLIdentity does not have to be generated with a DtlsIdentityStore[Interface/Impl] as part of the CreatePeerConnection steps because the certificate contains all the necessary information.
To create an RTCCertificate you have to do the identity generation yourself though. But you could reuse the same RTCCertificate for multiple connections.
BUG=webrtc:4927
R=tommi@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1288033009 .
Cr-Commit-Position: refs/heads/master@{#9774}
DtlsIdentityStoreImpl is updated to take KeyType into account, something which will be relevant after this CL lands:
https://codereview.webrtc.org/1189583002
The DtlsIdentityService[Interface] classes are about to be removed (to be removed when Chromium no longer implements and uses the interface). This was an unnecessary layer of complexity. The FakeIdentityService is now instead a FakeDtlsIdentityStore.
Where a service was previously passed around, a store is now passed around.
Identity generation is now commonly performed using DtlsIdentityStoreInterface. Previously, if a service was not specified, WebRtcSessionDescriptionFactory could fall back on its own generation code. Now, a store has to be provided for generation to occur.
For more information about the steps being taken to land this without breaking Chromium, see referenced bug.
BUG=webrtc:4899
R=magjed@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1176383004 .
Cr-Commit-Position: refs/heads/master@{#9696}
New PeerConnectionFactoryInterface::CreatePeerConnection taking both service and store added (old CreatePC signature still exists).
This is CL is part of an effort to land https://codereview.webrtc.org/1176383004 without breaking Chromium.
See bug for more information.
BUG=webrtc:4899
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1268363002 .
Cr-Commit-Position: refs/heads/master@{#9680}
Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
